SystemUpdate.AccessBootloader from debugger

I called SystemUpdate.AccessBootloader() on the EMX module while running from the VS2010 debugger.

This seems to have completely ruined my EMX module.

I was able to ping the EMX module in MFDeploy, but VS Studio constantly reports “an error occurred please check your hardware”

I booted into the GHI Bootloader and re-transmitted the TinyBooter.GHI, them with MFDeploy all the CLR.hex, CLR2.hex, and Config.hex files, but VS2010 still reported the “please check your hardware” message even though MFDeploy could ping the module.

I just repeated this process now and can’t even get into the GHI Bootloader to respond (pressing Up/Dn/Select + Reset or sending % over COM1) by any means.

Any ideas how to recover the EMX module?

I had been able to call PowerState.RebootDevice(true) in the debugger and although I couldn’t trace from the beginning of the reboot process, the debugger did seem to “re-attach” to the process after 30 seconds or so, so I thought it’d work for AccessBootloader() also.

Since I’d like to eventually get the in-field update working, for future reference, is it a bad idea to call SystemUpdate.AccessBootloader() while running in the debugger?

I waited a while and retried this and was able to get into the GHI Bootloader and get the system operating again with VS2010, so that leaves just the original question about whether or not you can call SystemUpdate.AccessBootloader() while running in the debugger?

Tried this one more time without the debugger running and SystemUpdate.AccessBootloader() shuts down my EMX module, although the device continues to respond to pings from MFDeploy.

The best documentation I can find on the in-field update is here:

How can I customize the Managed Bootloader? I don’t want to load files from the SD card, but receive them over one of the communucation ports of my device (e.g. COM or TCP).

Bootloader reserved size: The following amounts of FLASH are reserved for the managed booltoader once system update is enabled. The rest is for your main application.
USBizi: 48KB. EMX: 192KB. ChipworkX: 256KB.[/quote]

[quote]I just repeated this process now and can’t even get into the GHI Bootloader to respond (pressing Up/Dn/Select + Reset or sending % over COM1) by any means.

You are mixing 2 completely different things I believe. There is a “manged boot loader” that you can use to create your own loader in C#. This boot loader has no relation whatsoever with the native boot loader GHI use to update the module firmware.

native loader = press button on power up to handle, send %, use MFDeploy…etc. Always loaded by GHI at manufacturing stage

managed loader = something you can optionally write in C# and add to your device.

The documentation from GHI could be improved.

I’ve figured this out. Once you put the EMX into SystemUpdate.AccessBootloader() mode, you have deploy a separate program (with VS2010) that will make the calls to



and finally

that puts the EMX back into Application mode.

When you build your custom managed bootloader application in VS2010 for the EMX how do you know it will be smaller than 192KB ? Can you use the size of the .exe file generated as a guide? The size of the HEX file isn’t useful since it’s ASCII.

We always welcome contributions from the community if you are interested in adding a wiki page tutorial for infield update feature.

Hi Gus,

i wil try to post our code and some explanation if i have got some time left today (on the wiki). We also struggled a bit with the same thing. I had to read the text in the manual around 10 times (and do the same amount of tests) to understand it. It all seemed logically afterwards though, so i might be getting old :-[



We actually tried to improve the in field update description but it is not a simple feature and so there is no easy way to explain it. So maybe a tutorial with steps and example code would help.