MSD and binary file are not working together

[Jorge]

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!

[mark]

Hi

Thsi is typical behavior of an incompatible appliation configuration:

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 expects - 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.

If you don't work out the reason it is best to post your application binary fiel here so that I can check it and hopefully tell you what is going wrong.

Regards

Mark

[Jorge]

Hi Mark!

Thanks a lot for your support. I attached the archives.
I still need to define the interrupt function related to the Document Number: AN4498.

Thanks a lot again

[Jorge]

more docs

[Jorge]

Almost forgot the binary files.

I used the UtaskerConvert.exe in the CMD in order to translate the .hex file (generated by CodeWarrior) into .bin file.
I also attached the archives.

Regards.

[mark]

Hi

Presently the linker script file is not correct:

MEMORY {
m_reset (RX) : ORIGIN = 0x8080, LENGTH = 0x20
prog_flash (RX) : ORIGIN = 0x80a0, LENGTH = 0x80000-0x80a0
m_interrupts  (RX) : ORIGIN = 0x8080, LENGTH = 0x000001E0
m_text        (RX) : ORIGIN = 0x00000800, LENGTH = 0x0007F800
m_data        (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00020000
m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}

This is only locating the reset vector, interrupt vectors and program to be above 0x8000. m_text and m_cfmprotrom are still at their original locations which means that they overlap with the boot loader area. The result is that there is a large space between the two and the first bytes in the file belong to m_cfmprotrom (m_cfmprotrom is of no consequence for the application since the bot loader defines this area - it can be either removed or left as dummy data).

You need to do something like:

MEMORY {
m_reset (RX) : ORIGIN = 0x8080, LENGTH = 0x20
prog_flash (RX) : ORIGIN = 0x80a0, LENGTH = 0x80000-0x80a0
m_interrupts  (RX) : ORIGIN = 0x8080, LENGTH = 0x000001E0
m_text        (RX) : ORIGIN = 0x00008800, LENGTH = 0x0007F800-0x8000
m_data        (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00020000
m_cfmprotrom  (RX) : ORIGIN = 0x00080400, LENGTH = 0x00000010
}

In the resulting map file these shoudl be NO code or const data below 0x8080 - if there is there is an error.

The file raw.bin is also not correct. It contains HEX coding and is not binary (?) Check the use of the conversion program.

Regards

Mark

[Jorge]

Hi Mark!

I already changed the .lcf and the .map files like you suggested, I added the SECTION of the m_reset and prog_flash, I configured the Codewarrior (for the application) in the option "create Flash Image" -> Output File Format (-O): binary, and in that process generate a .hex file. I changed the name of the archive to testdefinitivo.bin and I converted the file in the CMD with the command: uTaskerConvert testdefinitivo.bin file2.bin -0x22ba -b267a8200926 and made another test with: uTaskerConvert testdefinitivo.bin raw.bin -b in a separate document.
But I still dont reach my objetive. I uploaded my binary file but my MSD dissapear, I reboot the device and the file uploaded, the LED blink and after centain time the LED mantain a logical one for 5 seconds and after that all the system collapse and stop it´s work.

do you know what is happening?

Regards Mark and thank you so much.

[Jorge]

I attached one application.
Can you send me a sample application?

Thank you.

[Jorge]

the .map

[mark]

Hi

The linker script looks correct but you have still incorrect locations in the map file:

.vectors        0x00000000      0x400
                0x00000000                __vector_table = .
                0x00000000                __VECTOR_TABLE_ROM_START = __vector_table


 .text          0x00000b40       0x44 C:/Freescale/Freescale_MQX_4_1/lib/twrk53n512.cw10gcc/debug/psp/psp.a(boot.o)
                0x00000b40                __boot

As you see, the vectors are at 0 and not at 0x8000.
The entry point is 0xb40 which is also not correct because it must be > 0x8000

Check carefully that you are actually using the correct linker script when building or that you are using the correct output file (maybe you are converting an old file that was built with the orignal linker script).


Also, DO NOT use the uTaskerConvert to create a binary file for loading with the USB-MSD loader. This is only used for the "BareMinimum" loader or an SD card/memory stick loader. It adds an authentication header to the file which will not allow it to be able to start if loaded with the USB-MSD card loader.


Basically you can do the following simple check:
- open the binary that you are loading in a binary editor and check the first 8 bytes.
- if these are
0x2000fc00
0x00008b41
(or similar) it is probably good.
- at the moment if you open the binary file you will see that it has some extra bytes (inserted by uTaskerConvert ) and the 0x00008b41 is 0x00000b41 which immediatly shows that it is bad. There is no point in loading a bad file since it will not run - first ensure that these are correct and then it has a chance to work.

Regards

Mark


PS. The uTasker application builds with GCC for both stand-alone and serial loader operation (generates two binary files) so this is the best application reference to use.

[Jorge]

Hi Mark

Like you said, I have:
0x2000fc00
0x00000b41 instead of 0x00008b41

I attached a pic, but I still dont understand why this is happen. I select Project->Properties->C/C++ Build -> Settings->Tool Settings -> Additional Tools-> Create Flie Image and the go to ARM Ltd Windows GNU create Flash Image->Output->Output file format (-O): Binary.
I don't why this is happen, the application I am trying to load it is an example of MQX.

Thanks and regards

[mark]

Hi

Check the linker setting to see which *.lcf it is actually using and then ensure that it uses the one that you have prepared.

Regards

Mark

[Jorge]

Hi

I attached an image that show the .ld archive. I configured that archive and I loaded for the test program.

Regards.

[Jorge]

Hi Mark!

I changed my App for a new one. I used the processor expert to make blink the LED E2 in my tower. I used the ProcessorExpert.ld and I change the variable _estack=0x20000000, for _estack=0x20005000 and the header of the binary file change. I remembered you told me the first byte is the stack pointer and the second one it is the entry address.

But I still don´t find the direct relation between SCB_VTOR register and the second byte of the binary file and also the address of the memory section m_interrupt.

Is there another variable to change in order to manipulate the second byte of the binary file?

I almost forgot to add SCB_VTOR = (uint32_t)(&__vect_table) in my App.

Thanks alot Mark.

[mark]

Hi Jorge

I don't now the details of PE projects but I don't think that anything else needs to be done apart from change the link address for the m_interrupt section - this is presumably the reset vector location.

Regards

Mark