Support for programming

[navnavnav]

Currently, Bloom only serves debugging operations. And whilst writing to target memories such as RAM and EEPROM is supported, Bloom cannot write to program (flash) memory. Bloom currently rejects any "write memory" commands from the connected GDB client, if the command addresses flash memory:

https://github.com/navnavnav/Bloom/blob/ead657b4af00bc3eec2cf57452a6cc34a1f4eb0b/src/DebugServer/Gdb/AvrGdb/CommandPackets/WriteMemory.cpp#L81-L85

Support for programming was briefly discussed in a previous issue, but I've been giving it some more thought and I'm now reconsidering.

My initial thoughts on how this would work (key points):

• Programming for debugging, not production
  • There will be no "program only" function.
  • Users should only use Bloom for programming when they intend to continue debugging/testing their modified code.
  • The objective is to allow users to apply changes to their code and test those changes using Bloom, without having to resort to using production programming software such as MPLAB IPE.
  • Bloom is not to serve as an alternative to production programming software such as MPLAB IPE or AVRDUDE.
• Starting small
  • To begin with, programming will only be available via the GDB session. Users will use the GDB load command to have GDB write to the program memory.
  • GDB will do most of the work - Bloom will just perform the write memory operations.
• In time, it would be nice if we could do the following:
  • Have users specify the path of their ELF binary in the project config file, and have Bloom keep an eye on it for changes.
  • On changes to the ELF file, have Bloom automatically update the target's program memory (maybe at the start/end of a debug session).
  • Generate a diff of the new code and only update the addresses in program memory that have changed, leading to potentially faster uploads. Though we can only write to flash in pages, so that's worth keeping in mind.

Those are just my initial thoughts on this. They will likely change as I progress.

---

I will not be starting work on this until there is clear evidence of demand. Please add a 👍🏽 reaction or leave a comment on this issue, expressing your interest. Work will begin when 10 or more Bloom users express an interest in this.

[septatrix]

Do you have any rough estimate when one could expect this feature? Is it weeks away or rather months?

[navnavnav]

Hi @septatrix

Due to the magnitude of the changes in v0.9.0, I've decided to push that release without this feature. This way, users can test the substantial changes made in v0.9.0 a lot sooner, and I'll be much more confident with subsequent releases.

So this feature will now be part of v0.10.0.

To answer your question, it will be about 6-8 weeks before development work on this will be complete. But that's just a wild estimate - it may take longer. I'll have a better idea when I begin work on it.

I'm looking to release v0.9.0 this weekend. Probably on Saturday the 7th. After that, I will begin work on this feature.

Thanks

[septatrix]

Due to the magnitude of the changes in v0.9.0, I've decided to push that release without this feature. This way, users can test the substantial changes made in v0.9.0 a lot sooner, and I'll be much more confident with subsequent releases.

:+1:

To answer your question, it will be about 6-8 weeks before development work on this will be complete. But that's just a wild estimate - it may take longer. I'll have a better idea when I begin work on it.

I'm looking to release v0.9.0 this weekend. Probably on Saturday the 7th. After that, I will begin work on this feature.

Sounds good. We might plan to use bloom in a larger fashion starting around october if that feature is implemented soon enough and we have time to check if it works for our purpose.

[navnavnav]

Quick update on this:

I've managed to get flash memory writes via the EDBG driver working correctly, support for the vFlashErase GDB command packet, and fixed a few bugs with memory address alignment in the EDBG driver.

What's left (briefly):

• Support the vFlashWrite GDB command packet (GDB uses this command packet instead of the X or M packets, when we provide it with a target memory map)
• A lot of testing

I haven't had much time on Bloom over the last few weeks. I'm hoping to spend the upcoming back holiday weekend to make some better progress.

[navnavnav]

Development work for this is complete. Will be publishing a new release in the next 2-3 hours.

[navnavnav]

Version 0.10.0 has been published. The new version can be downloaded from https://bloom.oscillate.io.

Closing this now.