cancel
Showing results for 
Search instead for 
Did you mean: 

Flash Memory Boot

kevin239955_st
Associate II
Posted on January 29, 2015 at 13:56

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''.

Thanks

Kevin
This discussion has been locked for participation. If you have a question, please start a new topic in order to ask your question
24 REPLIES 24
Erwan YVIN
ST Employee
Posted on January 30, 2015 at 10:15

Hello Kevin ,

Did you recover your board ?

Did you check if ''PLS Adapter'' is available on your device manager

Have you tried an ''Erase All'' ?

In our application the boot sector is : (cf boot.s)

0x015AXXXX is important to enable VLE

        /* BAM record.*/

        .section    .boot, ''ax''

        .long       0x015A0000

        .long       _reset_address

        .align      2

        .globl      _reset_address

        .type       _reset_address, @function

          Best regards

                     Erwan

kevin239955_st
Associate II
Posted on January 30, 2015 at 10:52

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=false
Erwan YVIN
ST Employee
Posted on February 02, 2015 at 18:16

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=false

2015-02-02_181503.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Wi&d=%2Fa%2F0X0000000ba2%2FZbrzoUoZxDNhR9F9kiNE0XvwtL0Xmb2RBILEfOKktjI&asPdf=false
kevin239955_st
Associate II
Posted on February 03, 2015 at 15:00

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=false
kevin239955_st
Associate II
Posted on February 18, 2015 at 16:42

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.

Kevin

disirio2
Senior
Posted on February 19, 2015 at 13:47

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.

Giovanni

kevin239955_st
Associate II
Posted on February 23, 2015 at 15:57

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.

Thanks

Kevin

Erwan YVIN
ST Employee
Posted on February 24, 2015 at 11:35

Hello Kevin ,

I have reproduced your issue.

If you put a bad boot_address like 0xFFFFFFFF

and 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 Assist

Mode (BAM) via SCI. The pins PA8 and PA9, (see Figure 12: User I/O pins PC4, PA8 and

PA9) 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 jumper

closed).

• 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

             Erwan

kevin239955_st
Associate II
Posted on February 24, 2015 at 13:00

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