This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
I have started getting a problem after flashing the first MCU in a daisy-chain and am not sure how to interpret the warnings.
I am using CCS 12.2.0 with C2000Ware 5.04.00.00, the debugger configuration shown in the screenshot below, and on a bare metal board that has been working correctly for over a year. After flashing the board, instead of running to main() as it usually does, it immediately gets a _system_post_cinit() software breakpoint, except that I haven't set one and I don't even have a function for this standard hook. After puzzling over this for some time, I noticed that there are 2 warnings in the console (circled in red below). I haven't noticed these previously. Has something bricked my MCU? I do not have anything special associated with these device zones - just the defaults.
Any ideas?
Thanks in advance for any insight that you can provide!
Don
Hi Don,
It appears the zone passwords may have been modified when you flashed the device. Which tool did you use to flash the device?
Kind regards,
Skyler
I used CCS 12.2.0 after having upgraded to C2000Ware 5.04.00.00.
I have another board (identical to the first) that is also getting these warnings, but it continues to flash and run.
Very strange. Ideas? Once it reaches this point, is the only solution to replace the 28x chip?
Thanks,
Don
I also upgraded SysConfig at the same time from 1.15 to 1.24 from the TI website, just in case that this is involved.
Hi Don,
Can you verify that the DCSM zone passwords shown in the On-Chip Flash Tool (Tools -> On-Chip Flash) are the same as what is reflected in the GEL file? You can find the gel file location within your Target Configuration file and you can view the passwords within the SetupDCSM() function of the GEL file.
Kind regards,
Skyler
Thanks for the detailed instructions, Skyler. I had a little trouble finding the gel files but finally found them at "C:\ti\ccs1220\ccs\ccs_base\emulation\gel\f280049c.gel". They have never been modified.
Using your instructions, I find that the gel file passwords (defaults) are identical to the passwords shown in the On-Chip Flash pane.
Next step? I see commands to lock or unlock and to program the passwords. I have never used this tool before...
Thanks,
Don
Hi Don,
Try unlocking the device with the default password. Is it possible that the DCSM passwords were programmed previously? I know that you mentioned it has been functioning for about a year now, but is it possible that the passwords were modified during the initial programming?
Kind regards,
Skyler
Hi Skyler -
I am the designer and only programmer of the board. I have never intentionally programmed the password. On a second board that receives the same message, I am able to continue to develop and flash new software, despite the warnings. It occurred to me that I should mention that at the same time that I upgrade the TI tool chain, I also re-jumpered the board to allow me to program both C2800049C processors with the same JTAG connector using a daisy-chain signal connection. I am using an XDS200 USB emulator pod. Another TI engineer warned me that the XDS200 due to an "unfortunate" bug is only able to support 2 MCUs on a JTAG daisy-chain and that I should consider switching to an XDS560 emulator. He didn't mention what the unfortunate bug was. Is it possible that it involves mangling the zone unlock command or something along that line? Just a thought.
Please don't close this topic down yet as I continue to debug this problem. I will program the passwords to the default configuration in the next day or so and post back here with the results...
Thanks,
Don
Hi Don,
Okay, I'll get in contact with some internal experts on possible the XDS200 issue you mentioned. Were you able to unlock the device through the On-Chip flash tool?
Kind regards,
Skyler
Hi Skyler -
Sorry for the late reply, but I found a resolution to the issue. Unfortunately, it appears that the XDS200 is the culprit in conjunction with daisy-chaining the JTAG of the two MCUs. The problem was only resolved by eliminating the daisy chain and programming only one MCU at a time. I have a request in to my managers to acquire an XDS560 for future use of daisy-chained JTAG capabilities. On one of the damaged prototypes, I had to replace the MCU to get it to work again after eliminating the daisy chain. On the other two prototypes I was able to unlock the MCUs through use of the On-Chip flash tool.
If you have any further information on the XDS200 issue, please let me know. Otherwise, this thread can now be closed.