Any way to upload new firmware without power cycling?

It's really quite a pain to go through the erase, reset, upload, reset cycle each time I make a change. Is there a way to do this all via software? I realize this would require changes to mchelper, but it sure would be nice to be able to upload new flash. I'm willing to write a bootloader and mchelper variant, if it is possible for the AT91 to program itself without a hardware erase step (bridging the erase jumper). Thanks!

Sure - this would definitely be a nice feature. I would definitely recommend taking a moment to look around at existing bootloaders for the SAM7X before jumping into writing your own, however. It's always easier to modify than to start from scratch! Also, it would be important to decide whether you want to communicate with the bootloader over USB or Ethernet. If you were going to do it over Ethernet, you could send the new .bin via HTTP POST through a webserver interface, for example, so you wouldn't need to make any mods to mchelper.

I've been thinking of implementing something like this as well. Having thought about it a while, it's a non-trivial amount of work, but something I think would really help MC developers. Here's a brief rundown of how I think it would need to work: 1) Basically, without a JTAG debugger, or some other external device, the MC would need to act as it's own LOADER. In the case of the MC, I suspect the easiest candidate would be a LOADING system that runs in it's own thread on the USB bus. The system would act as the following. a) When the system boots, it would automatically load as the LOADER. The LOADER would sit at the highest possible flash locations, and user application code would sit at the lowest flash locations. b) The bootloader would setup USB, and publish a custom USB interface (0xFF) that has 2 endpoints (one control, one bullk). The USB endpoints would be monitored by a controller thread (at the highest priority, blocked in USB input). The control endpoint would SHUT down the user threads, and enter the system into LOADER mode. The loader mode would sit at the end of the BULK endpoint, and accept an intel HEX or motorola s-rec of the user application code. c) When entering loader mode, the system needs to copy a routine to RAM. This routine is only for updating the flash. (The SAM7X flash cannot be updated from a program in flash, the progam needs to be executed from ROM or RAM. {As ROM is unavailable, it has to be RAM}) A stub for this routine is:

void flash_copy(char *inRAMAddr, char *inFlashAddr, unsigned size)
{
  // Disable interrupts
  // Setup flash for writing (I don't know if this is necessary)
  while(size--)
    *inFlashAddr++ = *inRAMAddr++;
  // Clean up flash writing
  // Re-enable interrupts
}

There is also the possiblity that this routine exists in the SAMBA boot loader, and we just need to figure out how to call it. (Possibly not worth the effort.) d) When data comes down the bulk endpoint, the srec or hex document is parsed, and flash_copy is called. e) After the entire record is copied, the part removes itself from the USB bus (i/o port pin gives functionality on MC), and resets (I can't remember how the SAM7X does this, but I recall reading it could do it's own reset). 2) We'd need to write the LOADER MC software, and some HOST side software for sending the srec/hex document down. Additionally, I think it's requirement that the user code be able to access the USB port as well, so the endpoints not taken by the LOADER should be available (there are 6 enpoints on the SAM7X, we'd need 2 -- I suggest 3 and 4). 3) I think the host side software should be linux/mac/Win, so it'd be easiest to roll it into mchelper, (and port mchelper to linux). All in all, I think this project is a fairly large amount of work. As you can tell, I have been thinking about it, and have actually started coding pieces of it. I wasn't planning on sharing my work (as parts of it are on company time), but I could be persuaded to rewrite the pieces I've done on the clock, and publish my work; however, I'd really only do this if others were involved. (In particular, I have NO interest in the windows MChelper work. {I've worked as an engineer for over 15 years, and I have never owned a windows box, and I never will. It's a source of pride for me.} Additionally, I have been busy lately so this project has been back-burnered, but I would happily work with others planning until my schedule clears. {As I need this capability in the work I will be doing with the MC, one way or another, I WILL be doing this work.}) Any takers???

This reminded me that there is a 'go' command in the SAMBA world that should theoretically start executing from a given spot in Flash...although this has never worked on the SAM7X256. I've looked around and seen people using it successfully on SAM7S chips, so there's some possibility that a bit of massaging could get it to work. I'll be sure to post if I find anything...

From liamMT: Also, it would be important to decide whether you want to communicate with the bootloader over USB or Ethernet. If you were going to do it over Ethernet, you could send the new .bin via HTTP POST through a webserver interface, for example, so you wouldn't need to make any mods to mchelper.

Well, that's an interesting point. Ideally, I could upload via a wireless connection. More importantly, though, I don't want to rely on any of the OS services to do the upload. I'm having lots of reliability issues with the OS, and eventually want to re-implement the code on the "bare metal," so to speak.

Also, are the original authors of the current bootloader and mchelper on the forums? Who are they? TIA, Rick

Jeremy - are you still on the forums? I'd certainly be interested in getting a nicer bootloader together. Please holler if this is still of interest to you - thanks!

Previously Liam Staskawicz wrote:

This reminded me that there is a 'go' command in the SAMBA world that should theoretically start executing from a given spot in Flash...although this has never worked on the SAM7X256. I've looked around and seen people using it successfully on SAM7S chips, so there's some possibility that a bit of massaging could get it to work. I'll be sure to post if I find anything...

If you're still interested in this, I've been using the 'go' command of SAM-BA to load images into my MC for awhile, now.  I'm not using the MC firmware, but the concept is the same.  It works fine (with a version of sam7 which has been modified to use the 'go' command).  Whatever firmware you load with it has to handle disabling and enabling the USB pullup so that it can re-enumerate to the host as no longer being the SAM-BA device.  Reset also must be set up so that the USB pullup gets similarly disabled and enabled, or else the host won't know that the SAM-BA device has returned.

I have code that handles that stuff if you want to see it.  It's not for the MC firmware, but the ideas in it ought to translate.

Sam7 also cannot flash to addresses other than 0x100000.    I'm currently using it with RAM images, which sam7 can load at arbitrary locations.  That's just sam7, though.  There's no reason that I know of why a SAM-BA client cannot flash arbitrary locations.  It just hadn't been done with sam7 last time I knew.

This scheme (using SAM-BA as a bootloader) does mean that every reboot requires a SAM-BA client to connect to the board to issue the 'go' command, even if the flash has already been loaded.  Either that, or set the boot-from-flash bit when no longer using SAM-BA to boot.  But then you're back to the original problem of having to reset to load new firmware.

What's been your strategy for inducing the board to go back into the sam-ba bootloader?

Previously Liam Staskawicz wrote:

What's been your strategy for inducing the board to go back into the sam-ba bootloader?

Mine?  Just don't burn the boot-from-flash bit and it'll go into the SAM-BA bootloader on reset.

Sorry I missed you in IRC. Do you have a strategy for dealing with watchdog kinds of situations where you need to the board to reset on its own from time to time? Ideally we'd all write code that never needed to be rebooted, but I've seen the need every now and again

Previously Liam Staskawicz wrote:

Sorry I missed you in IRC.

Do you have a strategy for dealing with watchdog kinds of situations where you need to the board to reset on its own from time to time? Ideally we'd all write code that never needed to be rebooted, but I've seen the need every now and again

Perhaps we can arrange a time.

There is a watchdog timer in the hardware, of course.  Is that the sort of thing you mean?  It might not be available booting from SAM-BA.  Once it is turned off (as the bootloader may have done), it can't be turned on again until reset.

Or do you mean to restart the same firmware without going through the bootloader?  That's certainly doable.  It's just jumping to an address.  Maybe resetting some hardware besides, but that can always be done in the startup code.  If you want to go the whole nine yards, you could remap flash into page 0 and start there at that time.

Heck, you can even hijack the reset line to do that instead of returning to the bootloader if you want to.  You could still return to the bootloader by power-cycling.  I don't think anybody besides me is using the reset line on the MC, though.

I reboot my board several times per day.  I've even got my test software doing it when the test is done, so SAM-BA will be ready for the next test.  Of course, when the test fails and doesn't get as far as the reboot, I'm back to bridging two pins on the JTAG connector with a metallic object.

Just by way of following up, I've been helping EBo test his changes to mchelper, and that requires me to run the MC firmware (heavy.bin, downloaded from the site).  I am using SAM-BA as a bootloader to do that, and it works fine.  After powerup, I run  arm-elf-sam7 -e 'go 0x100000' and the firmware starts running.  It does the right thing with the USB pullup, and enumerates as a Make Controller Kit.  In short, it's no different from when you set the GPNVM2 bit, except that you have to explicitly connect to it (sam7) to get it to start running the firmware.

My reset button (wired to the JTAG port) doesn't work, but that's just a matter of adding support for it to the firmware.  As discussed in IRC, it could either reset back to SAM-BA or disable interrupts and start running the firmware again (at 0x100000).  That decision could be made based on a bit in EEPROM (or a dipswitch or something else).  A software reset command should make the same decision based on the same criteria.  When GPNVM2 is set, either course of action (reset to firmware or reset to SAM-BA) would yield similar results (no SAM-BA).

Lou, If I am following you correctly, that should mean that we can install another checkbox in the preferences that would allow mchelper/builder to poke that bit explicitly... I like it! ThanX EBo --

Yup.  IIRC, that bit isn't even set (on a chip where it wasn't previously set) unless you've specified -e boot_from_flash to sam7.  So such a checkbox could simply control whether that argument gets passed.

Sam7 doesn't appear to let one twiddle GPNVM bits arbitarily, so, as far as I know, that is actually the only way to perform that function with sam7.  The MC firmware, of course, could do that once it's running.  If all else fails, bridging the erase jumper will clear that bit.

The same checkbox could add a "go" to the sam7 command line to start the firmware immediately after flashing it.  Some other UI element might do just the "go" part to start previously loaded firmware.

My copy of sam7 has been modified to restore the "go" command, which got removed at some point.  It may have been added back into the official distribution by now.  The underlying code was still there.  He just removed the command for some reason.  The patch to restore the "go" command was posted by somebody else in the sam7utils forum.