Problem with AN4368 USB bootloader on MCF52259

[ARQuattr]

I'm having trouble getting the USB host bootloader working following AN4368 on an MCF52259 processor. I tried using the project in the 'Codewarrior' folder for CW7.2, and also the 'CW10' project, but could get neither to work.

The CW 7.2 project compiled OK, however the CW10 project wouldn't compile until I changed exceptions_cfv2_c.obj(.vectortable) to exceptions_cfv2.obj(.vectortable) in the LCF file. It also didn't seem to open the .launch file so I created a new one but may have missed something. It also reported issues with certain paths, so I don't feel that project was set up properly.

Even once compiled, neither version executes. The CW7.2 version halts at the first instruction in _startup(), move.w #0x2700,sr. In CW10.1 it halts at jmp (a1) in Switch_mode().

I tried both of these projects on the MCF52259 tower and also another 52259-based custom board, with similar results.

I would also try to load the pre-compiled code as directed in the app note, except they are not included in the archive.

I had couple of other questions about this project - as I understand it this is a self-contained project and it doesn't rely on the MQX bsp or psp projects, correct? Also, it seems that to enable printf support I need to change #define NO_PRINTF 0 in exceptions_cvf2.c, and add #define CONSOLE_IO_SUPPORT 1 in exceptions_cvf2.h. Are there other things I need to be aware of?

Has anyone managed to get this bootloader working on an MCF52259 platform?

Thanks for your help.

[TomE]

> The CW7.2 version halts at the first instruction in _startup(), move.w #0x2700,sr.

Dump/print the memory locations at the address of _startup(). Make sure the PC has that value. The data probably won't correspond to that instruciton.

> In CW10.1 it halts at jmp (a1) in Switch_mode().

What is in Register A1 at that point?

Tom

[ARQuattr]

Tom, thanks for your reply.

In CW10, by the time it gets to that jmp instruction which is supposed to send it to the application image, A1 (and New_pc) = 0x4FEFFFE4.  At the same point, A0 (and New_sp) = 0x4E560000.

After digging into it a little more, it seemed the chip was not getting erased completely before flashing the bootloader so it was trying to jump to user application code that was not valid.  I used the default target task for MCF52259_INTFLASH, which includes a program with erase action, but perhaps it's only erasing the portion where the bootloader will be programmed (even though the 'restrict to addresses...' option is not checked).  (I tried to load the target task XML that came with the bootloader project files but it didn't work - nothing happened.)  So I added another erase action ahead of the others to do a chip erase.  After this, the New_pc value is loaded with 0xFFFFFFFF so the program doesn't try to jump there. 

So I managed to get it working in CW7.2 and CW10.1 on the tower board, but not the custom board.  Actually this board has a 52254, which I understand matches the 52259 with respect to memory addressing.  The board works fine and I've programmed it with other code no problem but I had to modify the lcf to get this to work.  There were some errors in these CW files (it was showing 256kB Flash space on the 52254 even though it has 512kB), and I have a feeling I'm running into the same issue here.  I will need to access the full 512kB since the added 48kB bootloader won't let me fit the application in the remaining 208kB, but I'm not clear how to adjust the .lcf and/or .mem files to get it working on the 52254 with the full 512kB (or even why that should be necessary).

Regards,

Angelo