Flashing new Master Brick firmware remotely?

[JavaLaurence]

Hi,

 

Is there any way to upgrade Master Bricks remotely, i.e. without having them hooked up to USB, and close enough to press a button?

 

Are there any plans to make this possible? If not, stacks embedded in hard to access places become a bit of a problem as far as upgrading is concerned..

 

Thx.

 

[photron]

Bricks can only be flashed via USB (or JTAG) interface. The Erase button has to be pressed during startup to make the microcontroller execute the bootloader that allows to flash a new firmware.

 

So there is no way to flash a new firmware without a USB connection.

[JavaLaurence]

This is a pain. Imagine stacks in really inaccessible places. Basically the current architecture means that such stacks are doomed to be frozen in time, as far as firmware improvements are concerned.

 

I think it would be a major new feature if Master Brick firmware could be upgrade via the normal communication mechanisms.

[borg]

With the microcontroller we are using this is unfortunately not possible. We would either need to add 512kb of external flash or we would have to limit the firmware size to 256kb.

[JavaLaurence]

OK, I see the problem. Maybe, just maybe, you could have a really tricky way to avoid needing exactly the same free buffer space as your firmware uses.

 

Let's say you have 512K physical, and your firmware is already 300K. Maybe it would be possible to download compacted patches that fit in the remaining buffer area. Then all you would need to do is have one tiny "patch loader" program (out of harm's way) which patches the existing firmware, and restart.

 

Assuming your firmware doesn't grow to 90% of your available space, and assuming your patches stay small.. this could work, no?

[borg]

In theory that is possible, but...

 

The patch loader needs to fit completely in the RAM for this to work, so it can't be too clever. Unfortunately small changes in the source code will result in big changes in the binary firmware if it is compiled with O3 by a modern C compiler.

 

So i am not sure how much you could do with this approach .

 

Another thing is: We would need to have two different procedures to flash the Bricks (you need to be able to flash the "normal" way, otherwise you couldn't rescue a Brick that has lost its firmware). I fear that the flashing process would then be even more confusing then it is already.