2015-01-29 04:56 AM
Hi
Section 6.1.1 of the SPC560x Reference Manual says that ''in order to successfully boot from flash memory, you must program two 32-bit fields into one of 5 possible boot blocks.''I have written 0x005A005A to address 0x00000000 accordingly (on our SPC56B Discovery Kit) but neglected to program a valid 32-bit reset vector. Now the board is stuck in reset (I can't even connect the JTAG probe).Is there any way of resolving this? Not just to ''unbrick'' the development hardware but if this were to happen ''in the field''.ThanksKevin2015-01-30 01:15 AM
2015-01-30 01:52 AM
Hi Erwan
No we have not recovered the board! I cannot Erase All since the the probe reports continuous ''Unexpected target reset detected !'' messages (see attached screenshot). Via the device manager I can select a ''PLS USB-JTAG Adapter'' and as mentioned this does connect successfully. However while the target is continually resetting I am unable to do anything with it. This development kit may simply be a write off but I would like to understand if this situation is irreversible or not going forward. Thanks Kevin ________________ Attachments : Unexpected_Target_Resets.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0X7&d=%2Fa%2F0X0000000ba4%2FfO73WFP3nJzWX4z97zQPFCrycGn4iGyePULQNezPPRo&asPdf=false2015-02-02 09:16 AM
Hello Kevin ,
Could you launch Target Interface and click on SELECT near FTDI Device , attached to USB Port ? (Cf Screenshots) Try with the external Alim.(5V) Best regards erwan ________________ Attachments : 2015-02-02_181346.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Ws&d=%2Fa%2F0X0000000ba5%2FqQnaly1lKUI1DnuFPEQE1TwvMWOxQ4EXoJs2_BGRdP4&asPdf=false2015-02-02_181503.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Wi&d=%2Fa%2F0X0000000ba2%2FZbrzoUoZxDNhR9F9kiNE0XvwtL0Xmb2RBILEfOKktjI&asPdf=false2015-02-03 06:00 AM
Hi Erwan
See screenshot, attached. I am not sure what ''external Alim'' is, but the Discovery Board is powered by the 12V currently (I'm debugging using a UDESTK attached to JTAG). To connect with USB to the embedded FTDI device I'll have to resolder certain solder points (you may have seen from a separate forum thread that we had to desolder to be able to use direct JTAG). Thanks Kevin ________________ Attachments : Select_Communication_Device.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Wd&d=%2Fa%2F0X0000000ba3%2FsTJfKTJsoMqoZ_lovtuhA94RtDYQ8_0hXfmHQqNUBsE&asPdf=false2015-02-18 07:42 AM
Hi
I am guessing from the lack of response that this is now a ''bricked'' processor that is now unusable. Please let me know if otherwise. Reproducing the problem is easy: write 0x005A005A to address 0x00000000 and an invalid boot address (e.g. 0xFFFFFFFF) to 0x00000004 and reboot. This renders the processor unusable. Other users take note.Kevin2015-02-19 04:47 AM
It could be the watchdog resetting the device continuously. Check the reset script in UDE and see if the watchdog is stopped there.
Erasing the flash should fix the problem if you are able to prevent the device from resetting. Without the board, it is hard to give a more detailed suggestion. Giovanni2015-02-23 06:57 AM
Giovanni
Watchdog is being disabled as part of the ''Initialisation Commands on reset'' script in UDE. The ''Unexpected target reset detected !'' errors continue to occur whether this is present or not. Is there another processor-driven reset that could be causing this, that we could inhibit using a UDE script?Also, I am more than happy to send you the board, if you are able to take a look.ThanksKevin2015-02-24 02:35 AM
Hello Kevin ,
I have reproduced your issue.If you put a bad boot_address like 0xFFFFFFFFand PLS & TRACE32 are stuck and the processor seems to be ''brick''To recover your board , please change the following jumper and try to erase the flash with PLS. (Cf below)It is possible to reprogram microcontroller internal flash programming using Boot AssistMode (BAM) via SCI. The pins PA8 and PA9, (see Figure 12: User I/O pins PC4, PA8 andPA9) have to be configured to enable the BAM functionality as following:• FABM (PA9) has to be connected to VDD_HV to enable serial boot (J13 jumperclosed).• ABS (PA8) has to be physically grounded to flash via SCI (J12 jumper closed).If the BAM function is not used, these pins can be configured as normal I/O according to the functions reported in the datasheet (see Section Appendix B: Reference documents). Best regards Erwan2015-02-24 04:00 AM
Erwan
I configured the jumpers as recommended and erased Flash memory. The board is no longer stuck in reset!Many thanks for your help, this is greatly appreciated.Kevin