EEPROM related issues with versions after 1.8 (LED goes from YELLOW to RED)
Closed this issue · 14 comments
Jtagulator stopped working for me starting with version c2af36a, first real change after 1.8 where EEPROM related changes were made. Version 1.8 worked fine and after that next substantial commit it failed to work, breaking in various ways depending on firmware version.
To investigate, I dumped the 24LC512 chip contents, flashed it to all zeroes, and then found that later versions worked fine.
Here is my EEPROM dump.
jtagulator-BorkedEEPROM.bin.gz
You should be able to flash this to the EEPROM, then flash the device with any firmware after 1.8 to the jtagulator to reproduce the issue.
Thanks for this. By "breaking in various ways," can you provide any more detail on what you were seeing? I'm assuming the problems are due to the initial unprogrammed state of the EEPROM and I might be missing a test/check before switching modes, but the more detail you can provide, the better.
An unprogrammed EEPROM from the factory will be all 0xFF. Can you please try your same experiment using 0xFF instead of 0x00 and see if that works?
Also, note that any commits pushed to the repo in between official releases are in-progress developments and may not be stable. Can you confirm you saw the problem with official release 1.9 or just the intermediate commits?
Thanks for this. By "breaking in various ways," can you provide any more detail on what you were seeing?
Usually on reset LED goes green and then a couple seconds later.. Red? The colors aren't clear to me. ;-) At this point the jtagulator does not respond to any input. No output is ever sent to the serial device.
However, some of the versions I tried when bisecting git gave error messages responding to input.. Something about not being connected to JTAG device I think, but didn't log them.
Can you confirm you saw the problem with official release 1.9 or just the intermediate commits?
Yes, this applies to 1.9.
An unprogrammed EEPROM from the factory will be all 0xFF. Can you please try your same experiment using 0xFF instead of 0x00 and see if that works?
Yes, sorry, I was incorrect.. What I actually did was clear it to all 0xFF, which fixed the errors I was seeing.
For what it's worth, using PropellerIDE to upload the jtagulator firmware.
So full steps to reproduce:
Write jtagulator-BorkedEEPROM.bin to the 24LC512 chip.
Compile and upload firmware 1.9 (or most any git version starting with c2af36a) using PropellerIDE.
When the jtagulator restarts, the LED goes green and then red, no serial output is sent, and no serial input is accepted.
Clear the EEPROM to all 0xFF.
Compile and upload firmware 1.9 using PropellerIDE.
When the jtagulator restarts, it should function as expected.
Thanks for this. By "breaking in various ways," can you provide any more detail on what you were seeing?
Usually on reset LED goes green and then a couple seconds later.. Red? The colors aren't clear to me. ;-) At this point the jtagulator does not respond to any input. No output is ever sent to the serial device.
OK, when the JTAGulator powers up and the LED goes green then solid red, this indicates that the JTAGulator is starting up in either the OpenOCD or SUMP mode (based on a flag set in the EEPROM). In a normal situation when you intentionally enter one of those modes, you can hit Ctrl-X from the terminal program to get back to a main menu. I have to test this with your BorkedEEPROM code, since it might return you but have undefined settings.
Clear the EEPROM to all 0xFF.
Compile and upload firmware 1.9 using PropellerIDE.
When the jtagulator restarts, it should function as expected.
Thanks for confirming. That's the behavior I'd expect.
I changed the EEPROM functionality during v1.8 and v1.9 development, so it's likely that there's a setting in the EEPROM that's causing the JTAGulator to start-up that way after a firmware upgrade (but behaves fine from a fresh install on a new board).
I'll look into it and see if I missed something.
I can confirm Ctrl-x does exit the mode.
So the following is expected behavior?
- Clear EEPROM
- Install 1.9 using PropellerIDE
- Enter OpenOCD mode
- Disconnect and throw in a drawer
- Pull out for use later
- Connect serial terminal and see no message
- Realize that red light means in a non-standard mode and hit Ctrl-x
If so it should be documented in the readme. I did search for what red light meant and found nothing useful...
That's correct.
The only caveat is you shouldn't need to clear the EEPROM before updating the firmware, so I think you found a bug that I'll investigate. The fix for that is to set the EEPROM to all 0xFF before loading version 1.9 or above as you did. Once you've done that, you shouldn't need to do that again for future firmware updates since I don't expect making changes to the EEPROM behavior on power-up.
The "LED will turn RED" behavior is referenced on the Wiki in the respective SUMP/logic analyzer and OpenOCD entries, but I will clarify it.
I haven't yet updated the main JTAGulator documentation to reflect all of the recent firmware changes (of which there are many).
FWIW, Propeller Tool is the officially supported compiler and I recommend using that. The other compilers may work fine, but they haven't been tested and I don't know what, if any, errors they may introduce.
I believe the device had a later firmware on it before my issue, which appears to be caused by my lack of understanding mode changes stay over reset/restart. So the only change that should be necessary is documentation helping others not to get stuck in the same state.
Just to confirm, you were able to properly update your firmware and intentionally entered OpenOCD mode, but then saw the red LED upon reset after that?
I had at some point upgraded the firmware (to 1.9? Or a git version close to that, not sure exactly) and had used openocd mode. I pulled the device out to use it again a week or so later and upgraded to latest git HEAD before using it, and subsequently found it was not responding as I expected. I reverted to 1.8 and found the device to work as expected. Then I figured out what commit caused the issue for me and made this bug report.
So the issue seems to be entirely I did not expect the device to remain in openocd mode after reset or power down, and did not know how to interpret the led status light which was the only indicator of status. I would recommend making this more clear in other parts of the documentation around upgrading and debugging and perhaps in the changelog, as this appears to be a major change in expected behavior. I probably won't be the last person to make this mistake. :-)
Thanks for the clarification - that makes more sense.
I originally thought you saw the red LED immediately after upgrading the firmware (but not having ever intentionally entered a secondary mode), which could have indicated a bug. I verified that I can successfully upgrade from a blank EEPROM to 1.7 to 1.8 to 1.9, so no bug there.
For the sake of completeness, your jtagulator-BorkedEEPROM.bin is an exact match of 1.8, though it includes flags used in 1.9 (stored in the upper 32KB portion of EEPROM that I use for keeping track of what mode the JTAGulator is in). The Propeller Tool only touches the lower 32KB of the 64KB EEPROM for firmware storage. The upper 32KB is only accessible by the user through code if desired and won't be touched by the Propeller Tool. So, whatever mode you are in when you do a firmware update will persist.
The flags indicate that you entered OpenOCD mode with a target I/O voltage of 2.1 and TDI, TDO, TCK, TMS set to 6, 9, 3, 1, respectively.
The reason 1.8 "worked" after you downgraded from 1.9 is because the EEPROM handling routine saw an invalid (for 1.8) setting in the EEPROM (mode 0x2 - OpenOCD - which doesn't exist in 1.8) and reverted you back to the main JTAGulator mode. This matches what you described in your posts above. If you had entered logic analyzer mode, that value would have been rewritten. If you had reloaded 1.9 without entering logic analyzer mode, the EEPROM handling routine would see a valid (for 1.9) setting and put you back in OpenOCD mode where you started.
The purpose of requiring the JTAGulator to remain in its secondary mode (logic analyzer or OpenOCD) until manually exiting with Ctrl-X is that some operating systems or applications assert DTR upon enabling or disabling the serial port. This causes the JTAGulator to reset, since DTR is used for programming the Propeller. So, if you exit the terminal program and then launch your external tool, the JTAGulator could be reset. If the mode setting doesn't persist across resets (essentially a soft power cycle), there would be no way to remain in that desired mode.
I'll leave this issue open until I update the documentation. The addition of secondary modes was a big change and I'm sure you won't be the last person to run into this.
First, thank you for all of the work you do on Jtagulator, it truly is an amazing tool.
I wanted to agree with the issue submitter's comment which said:
So the issue seems to be entirely I did not expect the device to remain in openocd mode after reset or power down, and did not know how to interpret the led status light which was the only indicator of status. I would recommend making this more clear in other parts of the documentation around upgrading and debugging and perhaps in the changelog, as this appears to be a major change in expected behavior. I probably won't be the last person to make this mistake. :-)
My workflow was similar to theirs:
- Upgraded to 1.9
- Entered OpenOCD Mode
- Powered off Jtagulator
- Powered on Jtagulator
- Received no input/output
- Assumed a critical bug / firmware corruption
I'm not sure where to put the warning about Ctrl+X and secondary modes relating to reboots/resets, but it seems that both the issue submitter and I missed this in the documentation.
Thank you again for all of the work you do!
Thanks for the feedback! I'm planning to put the warning in multiple places hopefully by next week:
-
Changelog
-
Wiki (Quick Start, FAQ, Logic Analyzer, OpenOCD sections)
-
In the code itself. When you enter one of the secondary modes, I'll have a reminder like:
Warning: This mode will persist through a reset or power cycle.
or
Warning: The JTAGulator will remain in this mode until manually aborted by the user.
If you or anyone else have suggestions for other places to clarify the behavior, let me know!
Once you get used to using the secondary modes, it makes sense. But, if you forget that you've entered that mode and come back to it later, that could be problematic!
Updated in all the aforementioned places!