Open mateusznowakdev opened 4 months ago
This is a characteristic of writing to flash storage in general: you can only write block by block.
it is a lot easier to used with a file system. For example I often use littlefs in the "unused" portion of the flash. See https://github.com/tinygo-org/tinyfs
Hi,
my program is locking up if the offset for
machine.Flash.WriteAt()
is not a multiple ofwriteBlockSize
(4). This is the code:and the broken output. No error message is displayed even if I try to handle the returned error value.
It works perfectly if
Output
is set to 0, 4, 8, 12, and so on.This can be fixed by adding up to
writeBlockSize-1
bytes with the value of0xFF
in front of the input slice, and updating the initial memory address for write. However, this will create a new temporary slice, being not efficient for large inputs.Before even trying to submit the PR, I'd like to know if it's expected that user can provide such invalid offset values. Maybe
panic()
king or returning an error would be enough.I've encountered the issue on both Seeed XIAOs I have. I don't know if the issue is present on other platforms such as RP2040 or STM32. But I see that the very similar
pad()
method is used there as well.