iMX28 Bare Metal Code and Boot ROM

[markwilliams]

Hi, I have created a bare metal memory test to run in the OCRAM of the iMX28. It is based on various OBDS and memtest applications in posts on these forums. I have used IAR for ARM to build the project and modified the elftosb bd file to suit.

Like others I have found that when I download using the usb loader I get an error but the code runs, albeit for a few seconds then stops. I know this because in my DDR test loop I output every 1MB tested and the count stops. However I find that if I re-run the USB downloader, although it doesn't do anything the test code resumes operation from the current MB count and runs forever more. Its like the first error leads to a hang and needs another kick from the downloader to recover and continue.

The error for the downloader is:

C:\D_Drive\Dev2\iMX28MemTest>sb_loader.exe /f test.sb
Downloading test.sb to device.
CStHidDevice::Download() Error(-13) during Write cbw.
Quitting.
Error(-13) during download.
Quitting.

C:\D_Drive\Dev2\iMX28MemTest>pause
Press any key to continue . . .

My test code will hang after a few seconds. If I re-run the downloader batch file it hangs in the command window but allows the code to run.

I also found that when the code is running from OCRAM if I unplug the USB cable used to download the image it immediately stops running. Why would the code executing in OCRAM stop when USB is disconnected?

I looked in the reference manual and found a few interesting points. It would seem that the boot ROM actually uses a portion of OCRAM so when using the downloader am I right in that you only have the lower 57K for applications? If so the bd file I have puts IVT at 0x1FF00 which would overlap onto boot ROM ram space:

sources
{
image=extern(0);
}

constants
{
IVT_ADDR = 0x1FF00;
}

section (0)
{
load image;
load ivt (entry = image:__iar_program_start) > IVT_ADDR;
hab call IVT_ADDR;

}

Also the above uses hab call. If I am jumping to OCRAM to run my code should I use hab jump instead of hab call? I have no intention of returning to boot ROM.

Finally when you jump from boot ROM using USB downloader into your own app I presume the USB peripheral is left configured still. Should custom code gracefully shut that down if it is not being used? Is this why my program crashes when USB is unplugged? Is the USB left configured by boot ROM and not being serviced by my app? Should I immediately disable the USB peripheral in my OCRAM app code?

Sorry lots of questions above - I have searched forums and read ref manuals to try and get the answers but just found lots of others who had similar problems with OCRAM test apps crashing or not running with no resolutions.

Thanks, Mark

[markwilliams]

I think I just found the answer to my question, and anyone else using bare metal USB downloaded apps that hang or crash.

I changed the bd file to hab jump rather than hab call (presumably the call means the ROM expects the code to return to it at some point vs the jump).

section (0)
{
load image;
load ivt (entry = image:__iar_program_start) > IVT_ADDR;
hab jump IVT_ADDR;

}

Now when I download via USB I no longer get the error message from USB downloader. Instead I get this:

C:\D_Drive\Dev2\iMX28MemTest>sb_loader.exe /f test.sb
Downloading test.sb to device.
.Done.
Waiting for Device Removal for 10 seconds...
Device Removal event.

C:\D_Drive\Dev2\iMX28MemTest>pause
Press any key to continue . . .

My code runs continuously without stopping. I can also remove the USB cable without it stopping.

So it seems hab jump is required in the bd file and not hab call.

BTW I also reviewed my addresses. But it was the above that cured the issue. I had thought IVT_ADDR in the bd file was interrupt vector table, not image vector table and tried tying the same addresses set in IAR. I now have IAR's interrupt vector table at 0x8000 (in IAR linker settings) and the image vector table at 0xC000 (in mx28evk.bd file for elftosb). But I did this before the change from jump to call and it still crashed. I think these RAM addresses still need to be this way to avoid trashing the RAM being used by the boot ROM after the first 57k of OCRAM.

Hope this helps someone else!

Would be good to get an NXP view on this!

Mark

[igorpadykov]

Hi Mark

thank for sharing solution. You are right, in general

"call" commands are expected to return to bootloader and "jump" commands are not.

Also only lowest 57K of OCRAM may be used for loading application data

according to sect.12.4 Memory Map i.MX28 Applications Processor Reference Manual

Best regards
igor