Connecting a JP1.1 remote via USB

[mathdon]

Does the EEPROM adapter work with the original C232HD-EDHSP-0 cable that you made?

Yes, and it works with pin 1 disconnected (that refers to 3FGs comment, see below).

Do you have a connection from +5 or +3.3 to pin1 of the adapter's flash side? There's a micro (pic12HV609) inside the adapter, and it needs power. In contrast, most remotes don't need a +V connection from the USB to serial converter because they use their batteries for power.

No, I did not have a connection to pin 1 on the flash side. I have now tried with it connected to the 3.3v line from the CP2102 board and it makes no difference, it still fails. I have looked at Kevin's circuit for the adapter and see that pin 1 of the input and output are connected together through a 100 ohm resistor, so the PIC chip can draw power from either side. I have tested with an FTDI cable using the adapter with pin 1 disconnected (see reply to Rob above) and that works, so it is not a power issue.

By putting debug statements into jp12serial, I find that the failure point is that the EEPROM adapter fails to respond to the "E" test, which I understand to be a "ping". Sending "E" with WriteSerial succeeds, ReadSerial fails to read a response. This suggests to me that the PIC chip in the adapter is inactive. I have no idea why, it is getting the same power from pin 1 of the remote whether I use the FTDI cable or the CP2102 board. So the more I find out about it, the more baffling it becomes . Any suggestions would be very welcome.

[mathdon]

I have done a lot of testing today as for my own peace of mind I would like to understand what is going on with this issue. My conclusion so far is that although I can see nothing in the specification of the PIC chip in the EEPROM adapter to indicate it, nor in Kevin's documentation, that the adapter acts like a JP1.2 remote and requires pin 4 to be low when pin 2 transitions from low to high in order to wake it up. The external 10k pull-down resistor seems sufficient to keep it low enough for a JP1.2 remote but perhaps not sufficient for the PIC chip of the adapter. I am wondering it it would be safe to try a lower resistor, say 5k. Any thoughts, anyone?

[3FG]

I believe that the adapter pays no attention to break signals, based on the ASM code. After a reset, I think it sets up 38kBaud and waits for commands.
http://www.compendiumarcana.com/jp1epa/ has the circuit diagram and asm file.
Tommy wrote up a procedure to test the adapter:
http://hifi-remote.com/forums/dload.php ... le_id=7959

He used RealTerm, but you can also use other programs that can manipulate the RTS line. I just tried XCTU with a JP1.3 remote and it was pretty easy to use. I skipped the USB and RF capabilities when installing it.
See the writeup at https://learn.adafruit.com/windows-tool ... l-terminal

The point is that testing with a serial terminal program is much faster and controllable than using JP12Serial. You should be able to quickly see if the adapter can communicate at all with the 2102 chip.

[mathdon]

I believe that the adapter pays no attention to break signals, based on the ASM code. After a reset, I think it sets up 38kBaud and waits for commands.

Dave, I absolutely agree with you based on reading the ASM code. I think the real question is what causes a reset? Pin 2 of the EEPROM adapter is connected to the active-low MCLR pin of the PIC chip. My belief, from the evidence below, is that pin 4 of the EEPROM adapter needs to be low (that is, in SETBREAK state) when MCLR transitions from low to high.

Here is my evidence. It is two tests from jp12serial code modified to test a ping of the adapter immediately. They are both made with a Tommy FTDI cable connected to a Tommy EEPROM adapter, so nothing to do with the CP2102N chip. The only change of code between the two tests is to the state of pin 4 when pin 2 transitions from low to high. As far as jp12serial is concerned, it is testing for JP1.1, hence the last line in each excerpt. This output is from DebugView.

Test 1, with pin 4 low on transition of MCLR

Code: Select all

Moving 
COM4
 to the head
Pin 2 set low
SETBREAK sent to set pin 4 low
Pin 2 now set high
CLRBREAK sent to set pin 4 high
Pinging with E test
Ping succeeded!
Passed JP1.1 test

Test 2, with pin 4 high on transition of MCLR

Code: Select all

Moving 
COM4
 to the head
Pin 2 set low
CLRBREAK sent to set pin 4 high
Pin 2 now set high
Pinging with E test
Read of ping return failed
Failed JP1.1 test

The PIC chip wakes up in test 1 but not in test 2. When I eventually got round to testing with an FTDI chip, these tests convinced me that the state of pin 4 of the EEPROM adapter on the flash side IS significant, even though I can find nothing in the PIC datasheet to support this.

[mathdon]

Well, I am now right out of ideas. I don't have Kevin's level of equipment, only an ancient analog meter but by lengthening the BREAK periods I have used that to see what happens on pin 4 using the CP2102N board (with 10k resistor between GND and TXD) with Tommy's EEPROM adapter on a download attempt of a JP1 remote, and also for comparison without the adapter on a download attempt of a JP1.2 remote. In both cases SETBREAK drops the pin 4 voltage from 3.3v to zero, the adapter ping (and so also the download) with the JP1 remote fails, with the JP1.2 remote both ping and download succeed. So my theory that 10k may not drop the voltage enough for the level to be recognised as low by the PIC chip is wrong. Without equipment that I do not have, I cannot see how I can investigate further why the CP2102N board will not communicate with the EEPROM adapter when an FTDI cable does so with apparently the same signals.

[3FG]

Graham,
I have never worked with PIC controllers, so I have only medium confidence in the following.
Line 26 of Kevin's code sets up the config register.

Code: Select all

__config _BOR_ON & _IOSCFS_8MHZ & _CP_OFF & _MCLRE_OFF & _PWRTE_ON & _WDT_OFF & _INTOSCIO

Brownout reset is enabled, code protection is off, external MCLR is disabled, Power up timer is enabled, watchdog timer reset is disabled, and it uses the internal oscillator at 8MHz. If I understand this correctly, it ignores the MCLR input in ordinary operation. The MCLR pin is also used to supply programming voltage, so perhaps (I don't know) its only use is in initial programming of the adapter.

Anyway, I think the adapter comes out of reset whenever power is applied or it recovers from low power voltage, and then it is active and should respond to commands. It stays active until power is lost.

why the CP2102N board will not communicate with the EEPROM adapter when an FTDI cable does so with apparently the same signals.

I know you prefer to use JP12Serial for these sorts of investigations, but you've actually demonstrated that JP12Serial doesn't communicate, which isn't quite the same as the CP2102N doesn't communicate. If you are willing to try a simple serial terminal program, I think you'll find that just attaching the adapter to 1) first a FTDI cable with power connected and typing "?" will get the help response from the adapter, and 2) attaching to the 2102 board will also work. According to my understanding, no RTS or break or anything else is required. Just power to the adapter. If the cable is supplying power, no remote is necessary to get responses to "I" and "V".

Of course, if I'm wrong about the the external MCLR, toggling RTS should provide a reset. Tommy's testing document seems to say that RTS should cause a reset.

[mathdon]

Dave, thanks for pushing me to try RealTerm. You are right, both the FTDI chip and the CP2102 board DO work with RealTerm. The adapter responds correctly to the E "ping" with an <ACK>, it identifies correctly with an I command and the EEPROM of the remote displays its contents with the d command, all with both FTDI and CP2102.

I do not regard my testing with jp12serial as wasted, as the ultimate aim is to get jp12serial to work with the CP2102 board with the EEPROM adapter, and at least I know now what does NOT work. It has, however, made it seem even more puzzling to me as it is clear (at least, my belief is that it is clear ) that jp12serial behaviour IS dependent on the BREAK state. Like you, I am also unclear about MCLR. I too had noticed that the assembler settings appear to disable the MCLR pin function yet Kevin's schematic clearly labels the line as MCLR. Ah well, more food for thought .

[3FG]

Kevin's schematic labels the inputs to the PIC as MCLR, ICSPDAT, and ICSPCLK. These are all names used in PIC documentation, and IMO Kevin used these labels to denote their usage during programming. See Section 4.0 of the Flash Memory Programming Specification, 41284E.pdf.

While the issue may relate to BREAK, another possibility may have to do with the exact timing associated with jp2_14Connect(), and dependent calls to jp2_14GetInfoAndSig and JP2_14StartOrStopComm. The latter function sends the string 0x00, 0x02, 0x51, 0x53, and 0x53 is ASCII "S". That will put the adapter into Send mode. I guess that eventually the adapter will decide that the data for the Send command doesn't have the correct start bit or other issue, and will probably revert to listening for other commands. In the meantime, JP12Serial will be listening for a "0" to indicate no error from a potential JP.14 or JP2 remote, and will eventually timeout, I think.

Anyway, it is an avenue to check while debugging JP12Serial, in my opinion.

[mathdon]

I HAVE SOLVED IT, in that I can download from a JP1 remote with the CP2102 board and the EEPROM adapter . I haven't solved it in terms of understanding why my fix works, and I would like to understand it. Perhaps 3FG or Tommy can explain, but here is the fix. Send the Info command, "?", read the first few characters of the reply, then clear the input buffer BEFORE sending the "E" ping. Somehow the "?" command appears to wake up the adapter in a way that the "E" command does not.

[The Robman]

Well done Graham, so a code change rather than a hardware change is what was needed, super cool.

[mathdon]

While the issue may relate to BREAK, another possibility may have to do with the exact timing associated with jp2_14Connect(), and dependent calls to jp2_14GetInfoAndSig and JP2_14StartOrStopComm. The latter function sends the string 0x00, 0x02, 0x51, 0x53, and 0x53 is ASCII "S". That will put the adapter into Send mode.

I have been using v0.26 of jp12serial, which I developed to handle JP1.1 as discussed earlier in this thread. That does a call to jp12Test (an "E" ping) BEFORE the call to jp2_14GetInfoAndSig, to test for one of the configurations that supports JP1.1. The debug excerpts in an earlier post above, labelled Test 1 and Test 2, were made with that (plus additional debug outputs), which is why the final line in those excerpts is pass/failure of JP1.1.test. The difference therefore is not to do with the adapter being put into Send mode.

I found the following test very informative with RealTerm, using a Tommy cable (which has power on pin 1) with the Tommy EEPROM adapter but without it connected to a remote. Start RealTerm, set up the serial settings, clear RTS, then send "E". There is no response. Next send "?". The info message appears. Now send "E" again. This time you get an <ACK> response. Now set RTS, clear RTS and repeat. Again no response from "E" until after a "?" command. I cannot explain this behaviour but it is what led me to try the fix that I found to work.

I now believe that it is only good luck that jp12serial has ever worked with the EEPROM adapter, even with an FTDI chip. Version 0.25 (and earlier) of jp12serial identifies the EEPROM adapter (plus FTDI cable) as connect type 5, which is JP12 Original. This means that jp12Test has been called four times, the first three failing and only the fourth succeeding. V0.26 is the same, except that there are four fails before the success and the first fail is before the call to jp2_14GetInfoAndSig. As you know, with the CP2102N chip ALL calls to jp12Test fail. By adding the call to the "?" command before the first jp12Test, the first jp12Test succeeds with both FTDI and CP2102N chips. This has the added advantage that jp2_14GetInfoAndSig is never called with the adapter, so avoiding any potential issue of the adapter being put into Send mode.

[3FG]

I'm glad you got it working, but I really don't understand some of the findings. If Kevin's hex file was generated from the asm file, meaning that the asm file accurately represents the firmware loaded into the PIC, then I don't see how manipulating the RTS line would affect the PIC operation. Are you sure that cycling RTS is the cause? Or perhaps the PIC isn't responding to every other command?

I do expect that asserting BREAK will affect the PIC, because BREAK is effectively sending 0x00 with a framing error (stop bits should be high, but in BREAK they will be low), and the PIC FW doesn't appear to check if a framing error occurred. As BREAK is unasserted, then depending on when TX went high compared to the PIC's processing of serial bits, it will receive a byte with the latter bits as ones and no framing error. I think this "command" will be 0x80 or higher, so out of the range of alphanumeric characters. The point is that asserting break will cause the PIC to see at least one command and maybe lots. None of the received bytes should be valid commands, so in principle no command is executed, but the PIC is busy dealing with the apparent transmission. I wouldn't expect any of this activity to affect successful reception of subsequent bytes, assuming that a delay of a couple of msec is provided by JP12Serial.

Anyway, I do agree with putting the check as the first thing. If that is done without asserting RTS or BREAK, then I think the risk of impacting any of the other connection types is quite low.

[mathdon]

I'm glad you got it working, but I really don't understand some of the findings.

Neither do I, but I am confident they are correct. I am not confident, however, that Kevin's schematic and asm code is the final design. You have already noted that the asm code appears to say that external MCLR is disabled, yet Kevin's schematic labels that line as MCLR, which is an apparent discrepancy. You are right that BREAK messes with the PIC, RealTerm bears that out, but I have carefully avoided a break being sent to the PIC, both in my testing with RealTerm and in my jp12serial code.

I do not have an adapter from DIYGadget, which as far as I know is the only source still available for them. Mine is from Tommy. I presume that the DIYGadget design is the same, but I would very much like someone with a DIYGadget adapter to test my new jp12serial, which is v0.27, before I release it publicly if possible. I have just finished what I hope is a final version of v0.27 and can post it in our file section for testing. If neither you nor Rob have a DIYGadget adapter then I may ask in the forum if a user who has one would kindly volunteer to test it.

[The Robman]

I have a DIYGadget adapter, do you want me to test it using a regular FTDI cable? Where should I get v0.27 ?

[3FG]

I don't think the MCLR represents a discrepancy. From the Flash Memory Programming Specification (41284E.pdf)

Code: Select all

Two methods are available to enter Program/Verify mode. “VPP-first” is entered by holding ICSPDAT and ICSPCLK low while raising the MCLR pin from VIL to VIHH (high voltage), then applying VDD and data. This method can be used for any Configuration Word selection and must be used if the INTOSC and internal MCLR options are selected (FOSC<2:0> = 100 or 101 and MCLRE = 0). The VPP-first entry prevents the device from executing code prior to entering Program/Verify mode. See the timing diagram in Figure 4-1.

Labeling the three lines as ICSPDAT, ICSPCLK, and MCLR seem quite reasonable to me. But OTOH I can't explain why setting/clearing RTS would affect the adapter.