Bootloader NACK

[jk1]

Posted on January 09, 2009 at 14:17

Bootloader NACK

[jk1]

Posted on May 17, 2011 at 12:53

On our custom board with STM32F101C8T6 we try to contact the bootloader from our custom download software.

When we send the 0x7f the board sends an ACK 0x79. No matter what command we now send the board sends a NAK 0x1F E.g. when we send 0x00 0xff the board responds with a NAK immediately after the 0x00 is send. What can cause this behaviour?

[16-32micros]

Posted on May 17, 2011 at 12:53

Hi,

Try first to run ST Flash Loader demo :

http://www.st.com/stonline/products/support/micro/files/um0462.zip

with your board, to know if the problem is coming from the customer Software you have used. Hope this helps. Cheers, STOne-32.

[jk1]

Posted on May 17, 2011 at 12:53

Thanks

We would like to do so, but we do not download from a PC but from an embedded system. Our application runs fine, including serial communication, when we download from JTAG. But we need to avoid the JTAG for production purposes. Our custom download software on the emdedded system runs perfectly with the Keil evaluation board. So to repeat my question: What can cause the bootloader to NAK on every single byte? Regards Jimmy

[gdp123a]

Posted on May 17, 2011 at 12:53

You've probably already done this, but just in case you haven't:

My suggestion would be to get an oscilloscope and compare the waveforms at the input pin of the STM micro (right at the micro - before any passive components). Compare the working version with the non-working version. Check that the embedded system is not sending two bytes very close to each other. Check the input of the embedded system in the same way. Receiving a NACK is better than receiving no response at all - sounds like you are very close to solving the problem.

[jk1]

Posted on May 17, 2011 at 12:53

Hello

Yes I've checked everything with a scope. This revealed only one problem. If you just keep sending 0x7f with no delays with e.g. 38400 baud while the MCU boots the timing will be wrong. The MCU will answer but the baud rate will be around 25000. But when we have a short delay from boot to sending the 0x7f the baudrate on the answer 0x7b (and the NAK's 0x1f on all the next bytes) is correct. Even with a long delay (>1 minute) my main problem still exists. I'm still a bit suspicious about the baudrate and will experiment further with this as I will try to connect at PC directly to the MCU (which is no easy task with the HW design). Regards Jimmy

[jk1]

Posted on May 17, 2011 at 12:53

Hello again

No luck with the baud rate. Tried chaging it in small steps after first ACK from bootload. All NACK's received. Connected the MCU directly to a PC. No change: 0x7f is ACK'ed. All command's after this point are NACK'ed. The ST Flash Loader demo does not get the job done. Works perfectly on the Keil Evaluation board. Does the hardware setup require somthing not mentioned in AN2606, which only states that the USART must be connected to PA9/PA10 and that the BOOT0/1 must be at the correct levels? Regards Jimmy

[jk1]

Posted on May 17, 2011 at 12:53

Hi

And thanks for your help. I can not see any difference on the RX signal on the scope. The 0x7f/ACK works fine. And when I download with JTAG and run my application the serial communication on the USART with the hardware is working fine. So I'm a bit in the dark. I will continue working on the problem and would appreciate any further suggestions. Regards Jimmy

[gdp123a]

Posted on May 17, 2011 at 12:53

I might be stating the obvious again:

You mention that the download works perfectly with the Keil evaluation board. Probe the input pin (PA10) on the evaluation board for comparison purposes. Just in case there is an issue regarding inversion of the signal or incompatible voltage levels. etc. Evaluation board to PC works. Evaluation board to Embedded system works. Sounds like a problem with your RS232 convertor (either on your custom board or more sensibly at the end of your production programming cable).

[jk1]

Posted on May 17, 2011 at 12:53

We have now tried a different hardware design with the same result!!!

Does anyone out there actual have the bootload running in a STM32F101C8T6?