Good afternoon,
I am creating a Booting from UART, and for this I analyzed the steps the boot via smart snippets performs, connecting two USB serial converters in the development board to verify the communication between external device and the module. The principle is the expected sequence, the module sends 0x02, the external device sends the 0x01, then the file size and the magnitude of the ACK. But following when external device is sending the code I realized that in the end is sent to sequence Booting 0x01,0x02 and 0x04 after finishing sending the .bin and before receiving the last ACK. I would like to know what you want are these values?
Device:
引导协议堤防ed inhttp://support.dialog-semiconductor.com/system/files/resources/AN-B-001%.... See section 6.2, table 5. The CRC byte that is sent by the DA14580 after the software code is simply an XOR of all bytes of the software.
You can also have a look in the SDK at tools/secondary_bootloader/src/uart_booter.c how this is implemented by the DA14580.
Good day,
The module is correctly sending the CRC, strange is the smart snippets after sending the code also send in the end the values 0x01,0x02 and 0x04, but after finishing the code the only expected answer is the module respond to the CRC, as AN-B-001 document. I will check the uart_booter.c code.
Are you booting the flash_programmer.bin software? If so, three bytes are appended to the software image indicating the GPIO VPP/UART settings. This is just a trick to customize the flash_programmer firmware for different configurations without having to have one binary for each configuration.
That's it. So I can send my flash_programmer.bin, and in the end these 3 bytes? and then usually follow in the footsteps of the document.
Yes. Note that the count of three bytes should be included in the 2-byte length header, since they are considered to be part of the application image.
thus carrying the code in ram, I can quietly use Extended sleep mode?
Yes. Extended sleep does not turn off any RAM.