Is it possible to program the Seed through the USART, SPI or I2C port ? I know the H7 processor used can do this but not sure if the Seed is designed to support it as the Boot pin is not routed to the main pins. Trying to use the Seed for an embedded application with occasional program updates so don’t want a USB cable or mini-JTAG cable hanging off it.
Pretty sure that there’s no pins usable for debugging on board sides. But you could open MCU datasheet and look for the list of alternative pin functions to confirm this.
Yes I did that. But the Seed has that separate SPI Flash memory for some reason, even though the processor itself has programmable Flash, so I was wondering if the designers had some fancy method to move programs from the SPI flash to internal flash as they would need to do this with every device in testing of course.
That’s because this MCU belongs to value line of its family. In order to make a high performance and cheap MCU, ST Microelectronics have equipped it with only 128k flash. More expensive units have got 1-2Mb. This size would be too restrictive for certain use cases (DSP module often use large amount of LUTs or it could be used to store samples). So Daisy is using external flash to deal with that fact.
It’s up to you to you to decide how to store data on that external flash, but it would be performed by your program. There’s an example of writing to QSPI flash.
Also note that you can’t just run firmware from external flash. It is possible in general, but first you need to make a bootloader that would initialize QSPI flash in memory mapped mode, then your app can run from the flash.
I think you’ve just given me the way. I program the MCU with a bootloader program that always loads in a program from QSPI on power on. After this the new program also monitors the USART and reloads the QSPI if there’s something there to load. And then a program reset once its loaded.
Does this sound logical or am I missing a gotcha ?
Generally yes. You won’t be able to write firmware update while you’re running application - you must return to bootloader mode. So all firmware updates would be performed by bootloader in indirect polling mode. The app itself will only receive a signal from UART that a bootloader is available and jump to bootloader, then notify UART that it can start transmission.
And you should add a few steps to prevent running unbootable code, i.e. make sure that there’s a valid program vector on flash before loading. If that happens, you should stay in bootloader and wait for valid firmware. Maybe add checksum calculation after writing firmware to confirm that no data corruption occurred.
There was a reference manual from STM about QSPI flash in H7 MCUs, it’s worth reading to better understand this stuff.
Btw, this is only necessary if your application + bootloader don’t fit into 128k flash. If they do, you could just use internal flash and it would make things easier.