Main Site Documentation

nXIP Program - need Deployment help! EMX module


#1

I’m getting this message when I boot EMX module:


EMX
TinyBooter Mode
Version: 4.1.6.0
Debug: COM1
LCD: 320x240
IP: 0.0.0.0
MAC: 00.00.00.00.00.00
Managed heap size: 1048580
Custom heap size: 0
TinyBooter v4.1.2821.0
EMX Build Date: Jun 30 2011 11:00:00
ARM Compiler version 410561
MSdbgV1O©
        Ô@ *** nXIP Program found at 0x00004000

I booted into the “Emergency Bootloader” but I’m still getting the error after resending TinyBooter.GHI. What’s the problem here and how to fix?


Force Boot Loader detected

GHI loader commands are now active
BL
BL
1.02
BL
Erase all memory! Are you sure?
BL
X11
BL
Start File Transfer
CCCCCCCCCCCCCCCCCCC
File Transfer Finished Successfully
EMX
TinyBooter Mode
Version: 4.1.6.0
Debug: COM1
LCD: 320x240
IP: 0.0.0.0
MAC: 00.00.00.00.00.00
Managed heap size: 1048580
Custom heap size: 0
TinyBooter v4.1.2821.0
EMX Build Date: Jun 30 2011 11:00:00
ARM Compiler version 410561
MSdbgV1z^ü¢a2**** nXIP Program found at 0x00004000

I’d like to point out that I didn’t do anything extraordinarily unusual here. I am turning up a set of new boards for a small production run and the previous board with EMX module was just fine.

The steps I followed were to deploy CLR, CLR2, Config - that worked fine - and then followed by deploying my application. Deploying my application resulted in an error message “check signature failed” after which the module went into this mode that I can’t seem to recover by redeploying TinyBooter.GHI.

This is the first time I tried to deploy my application using a file created with application deployment rather than using Studio to deploy. This is going to be important as I can’t have my production guys hitting F5 on Studio to deploy firmware.

I should point out that the deployment file was created with the exact same board previously turned up that is working great.

Any suggestions or ideas here on how to prevent this from happening again and/or recover from this state?


#2

This is not an error but actually normal!

What happens when you make a new console project and deploy it to EMX?

Your deployment is probably made on a device with firmware version X but then you are deploying it to device with firmware Y.

Make sure your original device + deployment + new device have same GHI SDK verison.


#3

I noticed that you have to hit capital ‘Y’ to erase firmware, not lower case ‘y’. I tried that and still same trouble.


Erase all memory! Are you sure?
Erasing....
******************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
Done.
BL
1.02
BL
X11
BL
Start File Transfer
CCCCCCCCCC
File Transfer Finished Successfully
EMX
TinyBooter Mode
Version: 4.1.6.0
Debug: COM1
LCD: 320x240
IP: 0.0.0.0
MAC: 00.00.00.00.00.00
Managed heap size: 1048580
Custom heap size: 0
TinyBooter v4.1.2821.0
EMX Build Date: Jun 30 2011 11:00:00
ARM Compiler version 410561
MSdbgV1z^ü¢a2*

but then I went to MFDeploy and selected ‘Clear Bootloader Flag’ and that seems to have resurrected it and enabled me to resend everything.

This might be caused by beginning lines of my application looking like this:


            SystemUpdate.SystemUpdateMode mode = SystemUpdate.GetMode();
            if (mode == SystemUpdate.SystemUpdateMode.NonFormatted)
            {
                SystemUpdate.EnableBootloader();
                PowerState.RebootDevice(false); // force a hard-reboot
            }
            if (mode == SystemUpdate.SystemUpdateMode.Application)
            {
                str = "System update mode= Application mode";
            }
            else if (mode == SystemUpdate.SystemUpdateMode.Bootloader)
            {
                str = "System update mode= Bootloader mode";
            }


If I have deployed programs in both application and bootloader memory areas of my target, will the MF Deploy “create application deployment” create a single image for these together? Or do I need to create one image when the module is in application mode and a separate image when the module is in bootloader mode and then have these deployed together at production?

Is even having the EnableBootloader line above compatible with creating an application deployment file since the memory partitioning changes the first time the deployed application is run?