MSD and binary file are not working together (utasker bootloader)

[migueltorres]

Hi everyone!

I have problems with the MSD. First, I load the binary file I found in this page: uTaskerSerialBoot_TWR-K53N512_KBOOT_HID_UART_MSD_SDHC.bin, I can see the MSD window. When I load the binary file (my little application) the msd show me the size of the binary file loaded. At then, the window of the MSD disappear and the blinking LED of the bootloader turn OFF. I tried to start my program but it is not working, after that, I pressed the reset button and the SW2 switch, again the MSD appear and I can see the binary file I loaded.

My program it is a blinking LED in the E2, instead of E1 (used for uTasker).

I changed the .lcf file with the specifications of the manual, I tried to use the uTaskerConvert.exe, uTaskerCombine.exe, I tried to changed the extension from file.hex (generated from CW) to file.bin.

I suppose the problem it is with the program I´m trying to load. There are certain thing that I still don´t understand.

The questions are:

How I can include the standard reset vector in my program?

my program is working at 50Mhz. it is this compatible with the uTasker?

do I need to reset the state of the ports in the begin of my program?

somebody know why it is not working?

I attached the pics for better understanding.

Thanks and regards!

[mjbcswitzerland]

Hi

You can get a list of things to check for compatibility in appendix B of http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

The reset vector of the application needs to be located at the start address of your application (that is the address that the serial loader expectes - 0x8080 for the default USB-MSD loader).

There is no requirement for the application clock speed but beware that the serial loader will program this to a certain speed so that it can work and a typical problem with clock initialisation at the application is that it can't handle the case that the clock is already configured (and often hangs). If you set the serial loader's clock values to the same as the application need you can simply remove the application's initialisation to avoid such difficulties with poor initialisation code that is often encountered in simple libraries.

There is no need to de-initialise any ports or other peripherals at the appication since the serial loader does this before jumping.

It is usually simple to work out why the application is not operating:

1. Check the applications binary to verify that the first two long words are as expected (the first is the stack pointer's initial value and the second the entry address - as is typical for the reset vector); if they are strange there is something wrong with the location of the reset vector.

2. Then connect the debugger and set a break point at the entry point of the application - it will be hit when the boot loader jumps to the application and you can debug the code as normal; sometimes there are issues with the application's watchdog initialisation being too slow to unlock the watchdog when running at full speed - removing this will solve it or ensure that the code used is not poor code that uses too many instructions to do the work.

3. If you can verify that it starts the final, and most common remaining problem, is that the interrupt vectors/vector table are not configured correctly - this is discussed in more detail at the link.

In case of problems it is best to simply post your applicaton binary at the uTasker users forum (noting which Freescale eval board it can be loaded to) and you will have a professional developer check it out for you and tell you what is going wrong (this is "usually" easy to see by simply connecting a debugger and stepping the assembler code).

Regards

Mark