Main Site Documentation

ChipworkX deploying in bootloader mode!


#1

Hi all,

I have finally figured out or at least I think I know how the IFU works with 4.1

I have, through code, set the CodeworkX module to Bootloader mode and now when I reset it shows Deployment Bootloader Mode on the LCD.

I have written a boot loader that will flash the application from the SD card but I get an error when I try to deploy this to the device.

It shows “An error has occurred. Please check your hardware” in the Error List and the bottom of the screen shows Deploy Failed.

The ChipworkX module is being detected and I have it selected.

Any idea what is wrong and why I can’t program this?

ALSO… How do I get the board back into Application mode without having anything running? Last time I did a full erase and reprogrammed the TinyBooter :frowning:


#2

I haven’t done IFU with 4.1, but compared with 4.2 IFU it sounds way to complicated what you do. In 4.2 you just, Init -> load files -> Finish (which makes a single reboot)


#3

Quick question.

What’s the max size of the bootloader application? I have a feeling that my file s too big and why there is an error.


#4

Thanks Reinhard.

There is no choice just now with ChipworkX. The only option is the complex way.

I have managed to deploy the Pyxis Updated (modified for my use) but it does not run on boot up and I can’t get the board back into application mode. :frowning:


#5

OK. I have it working.

With a little help from the Pyxis code I was able to work out that it was a size issue. I can’t use Glide to create my updater application so I used the same idea that Pyxis used with bmp text and now I will be able to update the machines in the field.!

I can now enjoy the weekend. Hope it don’t rain now. :slight_smile:

Dave…


#6

Oh rats!! One slight issue.

Well it all works nicely but for one thing!!!

The touch screen needs to be recalibrated when I update the system and the new application starts. This is not ideal for a standalone application that won’t likely have an operator standing by the do this!

I’ll have to look into the touch driver to see if I can store these on the flash disk and recover them when the applications starts.


#7

@ Dave McLaughlin -

Maybe you’ll discover that calibration should also be done regularly as it can change in the lifetime of the module ! Not sure a default calibration will be an issue, or you will have to implement big controls to avoid ranslation problems…


#8

Thanks LuisCpro.

For 99% of the time, these units are left unattended and hardly need any operator input other than initial installation and configuration. I have an option to start the calibration on bootup by holding down a button so I can still gain access to this part.

I’ll need to add code now to save the calibration to flash and then check if it exists on a reboot and simply copy it back. This will get around the issue for me on reflashing with new application code.

Is a small annoyance but far less than not having the ability to remotely update them which I now have.