USART protocol used in the stm32 bootloader write command problem

[DamjanTasevski]

The MCU I'm using is STM32F743H7IIT6.

I am trying to perform firmware update via the USART bootloader protocol. (AN3155
Application note)  Everything was working fine with many .bin files until one .bin file crashed the update. When I debuged I found a command that doesn't receive any response.

31 ce

 good ACK received

080163006a 

(address) good ACK received

5bed5f0108ed5f0108ffffffffffffffffffffffffffff000001004153434949000000000000000000000000000000000000000000000000000000415343494900000000000000000000000000000000000000000000000000000000005a

Nothing is received back. (5b is the number of Bytes followed by 92 bytes and 5a is the checksum)

I tried with 59, 5a, 5b, 5c, 5d as the number of Bytes and every time nothing

I tried writing 03 ff ff ff ff 03 on the same address and it's working.

Also tried longer Byte Arrays with ff number of bytes and they work.

(I didn't bother very much with the checksum, as it should return NACK if the checksum was bad)

Any help appreciated, 

Thanks

Update 1:

I've now tried the same Byte Array with incorrect checksum, it is giving me NACK

Update2:

Adding 4 bytes works

5fed5f0108ed5f0108ffffffffffffffffffffffffffff00000100415343494900000000000000000000000000000000000000000000000000000041534349490000000000000000000000000000000000000000000000000000000000000000005e

Removing 4 bytes doesn't work 

57ed5f0108ed5f0108ffffffffffffffffffffffffffff00000100415343494900000000000000000000000000000000000000000000000000000041534349490000000000000000000000000000000000000000000000000056

[DamjanTasevski]

I've now tried the same Byte Array with incorrect checksum, it is giving me NACK

[DamjanTasevski]

Update2:

Adding 4 bytes works

5fed5f0108ed5f0108ffffffffffffffffffffffffffff00000100415343494900000000000000000000000000000000000000000000000000000041534349490000000000000000000000000000000000000000000000000000000000000000005e

Removing 4 bytes doesn't work 

57ed5f0108ed5f0108ffffffffffffffffffffffffffff00000100415343494900000000000000000000000000000000000000000000000000000041534349490000000000000000000000000000000000000000000000000056

[TDK]

Let's be objective here:

If the update crashed, the bootloader has remained unchanged as it's in ROM. It performed the same before and after the crash event.

Perhaps a bug in your software which handles the event. Perhaps a signal integrity issue, can you view it on a scope?

[DamjanTasevski]

I said the update crashed because the software that handles the update didn't receive ACK. The bootloader is definitely unchanged because I'm writing to different address where the main code is stored.
I actually don't know if the command was accepted by the bootloader because those 90 bytes didn't make a difference in the 100KB code.

Anyway, everything I tried after that was through Serial Port monitor, focusing only on this one command and why is it not receiving ACK even though it is formatted according to the datasheet.

Currently I bypassed the issue by appending 0s to every chunk of data that is less than 255 bytes.