cancel
Showing results for 
Search instead for 
Did you mean: 

Inter Byte Delay while sending Bootloader commands on STM32f030xC

aatif shaikh
Associate III

Dear All,

Currently we're using STM32F030CC micro controller to make a programmer which will program STM32F030CC serially via UART Bootloader commands.

First we verified / noted the response of every command by sending each command via serial monitor.

Then as we got to know the sequence in which the commands are needed to be sent we programmed the Programmer STM which will send the appropriate commands in the proper sequence on every ACK received.

Issue:

After sending AutoBaudDetection command ie 0x7E we get the response as 0x79 as an ACK.

After that we sent Extended Erase Memory command ie 0x44 0xBB. We received response as 0x1F meaning NACK for the above command.

The same command sequence works fine when we send the sequence via the serial monitor but results into NACK response when sending through a program.

This was looking as a timing issues so we added some delay after sending each byte from the Programmer MCU.

So after waiting for about 22ms between each byte transfer (inter byte delay) we're getting proper response of all the commands. With this delay we were able to successfully program a file of 8KiloBytes on to the target STM.

But the question is why the target device is taking this much time to process the commands? It took us about 3 mins to program a file of size 8KiloBytes.

Does the STM needs some time between the commands to process a particular command? Also the document which has the Bootloader commands doesn't mention any timing constraints on commands.

Also we're communicating on115.2Kbps.

Any suggestions about this issue will be appreciated.

Regards,

Aatif.

@Community member​ 

@Community member​ 

@Community member​ 

@Pavel A.​ 

5 REPLIES 5
AvaTar
Lead

> After sending AutoBaudDetection command ie 0x7E we get the response as 0x79 as an ACK.

> After that we sent Extended Erase Memory command ie 0x44 0xBB. We received response as 0x1F meaning NACK for the above command.

> The same command sequence works fine when we send the sequence via the serial monitor but results into NACK response when sending through a program.

I never implemented a flasher for ST's system- BL myself.

But your description above des not imply that a 22ms delay is necessary after EVERY byte - only after the initial ACK.

Have you checked the timing of ST's Flasher during programming, i.e. the actual data transfer ?

BTW, erase operations might actually take long.

aatif shaikh
Associate III

@Community member​ 

> Have you checked the timing of ST's Flasher during programming, i.e. the actual data transfer ?

Do you mean the standard application software which downloads the program?

If yes, then yes. ST's flash tool hardly takes 3 secs to erase and program 8 KiloBytes of code.

Regards,

Aatif.

AvaTar
Lead

Yes.

But I mean specifically the inter-character delay when ST's Flasher transmits the actual application data (8kB), with a scope. The 3 seconds would give plenty of time to hit the "Stop" button on the scope manually.

I would expect significantly less than 22ms.

Pavel A.
Evangelist III

So, what is the "standard application" you use to program: ST-Link Utility? Cube Programmer?

On Windows or Linux?

Baudrate 115200 is maybe too high, try 38400. The higher baudrate, the more precise clock you need.

-- pa

aatif shaikh
Associate III

@Pavel A.​ 

We're using ST's flash loader as a standard application tool to download the code. In that the elapsed time shows 2-3 seconds for flash erase and code download combined.

We'll try lowering the baud rate in the code. We had kept 115.2 Kbps because we used the same baudrate while programming through ST's Flash loader tool.

@Community member​ 

I do not have the Digital oscilloscope at hand right now. But i'm sure that i'll be lot less as 8 Kb of file is getting written in 2 seconds along with erase operation and other book keeping commands.

Regards,

Aatif.