Tools for MIMXRT1062 ROM Bootloader Serial Downloader

[anthony_asterisk]

I have a project where the intention is for the image to execute entirely in RAM and to use the ROM bootloader in serial downloader mode to load the application.  The board uses MIMXRT1061DVL6B but I am doing my initial development on MIMXRT1060-EVKB (MIMXRT1062)  

I found some documentation on the serial downloader protocol in the Reference Manual. 

Is there an available SDK for communicating with the serial downloader?  

Is there a demo tool that I can run on my desktop platform for initial testing?

This project is using Zephyr for the application, however I feel these questions are not specific to Zephyr so I have posted here as well as asking questions in the Zephyr discussion boards..

[mjbcswitzerland]

Hi

There is an off-the-shelf boot loader for the i.MX RT 106x here: https://www.utasker.com/iMX/RT1060.html
This allows any application to be programmed to QSPI flash (also AES256 encrypted) and run from RAM in order to obtain maximum performance (zero wait state instruction and data access). It automatically configures the FlexRAM according to the code size to fit the code in ITC and use the rest for data in DTC.
See the video demo at https://www.youtube.com/watch?v=fnfLQ-nbscI&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe&index=11

I don't know that using the ROM loader would help since this only allows writing to RAM from an external source via LPUART or USB using its SDP protocol. However the uTasker project also includes this capability (used for production programming from on i.MX RT to another) - see https://www.utasker.com/docs/iMX/uTasker_iMX-RT-Programmer.pdf

Regards

Mark (uTasker project lead)

For our discounted i.MX and Kinetis stock availability see https://www.utasker.com/Shop/semi.html

[anthony_asterisk]

This board will not have any flash available, I need to find out more about the ROM image serial downloader, the board will always be USB connected to a host system that will provide the image. 

[mjbcswitzerland]

I see.

In that case you need to use blhost (as used by the MXP-MCUBootUtility) and you could ask the owner of that project for info.

The SCP protocol is in fact explained in the MIMXRT1062 user manual.

For someone who can control HID class on a PC, the USB host needs to detect a connected device with VID / PID 0x1fc9 / 0x0131 to recognise the processor in ISP mode and then can use a few commands in order to program data to RAM and issue a go command.

I am not a PC developer but it was simple to do on another i.MX RT in USB host mode - these are the commands that it is based on:

static int fnSDP_start(int iCommand)
{
    switch (iCommand) {
    case 0:
        fnSDP(SDP_COMMAND_TYPE_ERROR_STATUS, 0, 0, 0, 0);                // start SDP sequence setup (and prepare its data)
        break;
    case 1:
        fnSDP(SDP_COMMAND_TYPE_READ_REGISTER, (unsigned long)HW_OCOTP_CFG0_ADD, SDP_FORMAT_LONG_WORD, 0, 1); // start SDP sequence setup (and prepare its data) - read UUID0
        break;
    case 2:
        fnSDP(SDP_COMMAND_TYPE_READ_REGISTER, (unsigned long)HW_OCOTP_CFG1_ADD, SDP_FORMAT_LONG_WORD, 0, 1); // start SDP sequence setup (and prepare its data) - read UUID1
        break;
    case 3:
        fnSDP(SDP_COMMAND_TYPE_READ_REGISTER, (unsigned long)SRC_SBMR1_ADD, SDP_FORMAT_LONG_WORD, 0, 1); // start SDP sequence setup (and prepare its data) - SRC boot mode register 1
        break;
    case 4:
        fnSDP(SDP_COMMAND_TYPE_READ_REGISTER, (unsigned long)SRC_SBMR2_ADD, SDP_FORMAT_LONG_WORD, 0, 1); // start SDP sequence setup (and prepare its data) - SRC boot mode register 2
        break;

    case 6:
        fnSDP(SDP_COMMAND_TYPE_WRITE_FILE, (unsigned long)LOAD_ADDRESS, 0, 0, ulFileLength); // start SDP sequence setup (and prepare its data)
        break;
    case 7:
        fnSDP(SDP_COMMAND_TYPE_JUMP_ADDRESS, (unsigned long)LOAD_ADDRESS, 0, 0, 0); // start SDP sequence setup (and prepare its data)
        break;
    default:
        return 1;
    }
    return 0;
}

You can find the command in the user's manual as follows:
#define SDP_COMMAND_TYPE_READ_REGISTER 0x01
#define SDP_COMMAND_TYPE_WRITE_REGISTER 0x02
#define SDP_COMMAND_TYPE_WRITE_FILE 0x04
#define SDP_COMMAND_TYPE_ERROR_STATUS 0x05
#define SDP_COMMAND_TYPE_DCD_WRITE 0x0a
#define SDP_COMMAND_TYPE_JUMP_ADDRESS 0x0b


Regards

Mark

[anthony_asterisk]

I think I made some progress but I still have some things  I need to understand further.

The Rom-based bootloader only supports SDP.  This is not compatible with blhost.  I installed spsdk to get the sdphost tool, which is able to handle SDP.

After installing I'm able to run:

(.venv) C:\Users\antho>sdphost -u 1fc9 write-file 0 d:\AAA\tree\build_evkb\zephyr\zephyr.bin
Status (HAB mode) = 1450735702 (0x56787856) Hab Is Disabled (Unlocked).
Response status = 2300781449 (0x89232389) NO DESCRIPTION.

(.venv) C:\Users\antho>sdphost -u 1fc9 jump-address 0x22c0
Status (HAB mode) = 1450735702 (0x56787856) Hab Is Disabled (Unlocked).

After triggering the jump, the device disconnects from USB but afterwards does not enumerate as a USB COM port as it normally does during debugging with this image.

My questions at this point:

 is zephyr.bin is the correct file/format.. for example does it have the isr table?
what address should I the write it to?
what address to jump to after its written?

BTW - I am building this project with zephyr.  It has been compiled to run entirely from ram and i have it working when I download the image via the debug probe.   (west debug -d build_evkb)

[anthony_asterisk]

Hi @mjbcswitzerland 

I downloaded the blhost tool.  On the dev board MIMXRT1060 EVKB I set SW4 jumper 3 to 1 and jumper 4 to 0.  I also erased all the memories using the debugger interface.   After I reset I can see the device enumerates on to USB with VID 1fc9 and PID 0135

(.venv) D:\AAA>usbipd list
Connected:
BUSID VID:PID DEVICE STATE
1-1 1366:0105 JLink CDC UART Port (COM9), J-Link driver Not shared
1-2 1fc9:0135 USB Input Device Not shared

When I try to use blhost to communicate with the serial downloader I don't get a response:

blhost_2.6.7\blhost_2.6.7\bin\win\blhost.exe --u 0x1FC9,0x0135 -- get-property 1
Inject command 'get-property'
sendCommandGetResponse.readPacket error 5.
Response status = 10004 (0x2714) No response packet from target device.

blhost_2.6.7\blhost_2.6.7\bin\win\blhost.exe --u 0x1FC9,0x0135 -- reset
Inject command 'reset'
sendCommandGetResponse.readPacket error 5.
Ignoring missing response from reset command.
Response status = 0 (0x0) Success.

Is there another step I need to do before blhost can communicate directly with the ROM serial downloader?

[mjbcswitzerland]

Hi

When I load code (that runs in RAM) I use these two steps in the sequence:

case 6:
fnSDP(SDP_COMMAND_TYPE_WRITE_FILE, (unsigned long)LOAD_ADDRESS, 0, 0, ulFileLength); // start SDP sequence setup (and prepare its data)
break;
case 7:
fnSDP(SDP_COMMAND_TYPE_JUMP_ADDRESS, (unsigned long)LOAD_ADDRESS, 0, 0, 0); // start SDP sequence setup (and prepare its data)

LOAD_ADDRESS is defined to be
#define LOAD_ADDRESS 0x20208200 // in OCRAM
since the code that is load is linked to operate there (the FlexRAM defaults are valid).

The file that I load has an image vector table at the start - this is its binary:

0xd1,0x00,0x20,0x40,0xf9,0xad,0x20,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, // 0x00..0x0f
0x00,0x82,0x20,0x20,0x00,0x82,0x20,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, // 0x10..0x1f
0x00,0x82,0x20,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, // 0x20..0x2f
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, // 0x30..0x3f
...

whereby the image vector table is defined as

typedef struct stIMAGE_VECTOR_TABLE_LOADER {
unsigned long hdr; // header tag that must be IVT_HEADER
unsigned long entry; // absolute address of the first instruction to execute from the
unsigned long reserved1; // reserved in this version of HAB (high assurance boot): should be NULL
unsigned long dcd; // absolute address of the image DCD: may be NULL
unsigned long boot_data; // absolute address of the boot data: may be NULL, but not interpreted any further by HAB
unsigned long self; // absolute address of the IVT
unsigned long csf; // absolute address of the image CSF
unsigned long reserved2; // reserved in this version of HAB: should be zero
unsigned long ulEntry;
unsigned long ulLength;
unsigned long ulRes[118];
} IMAGE_VECTOR_TABLE_LOADER;

Therefore you can't load the same image as you load with the debugger (which will start with a reset vector).

When I build my own projects I use a define "SDP_LOADER" to control outputting two binary files - one that can be loaded with the debugger (and other standard techniques) and one that can be loaded via  SDP. That define controls inserting the necessary header and a few other changes (which are more due to the fact that I build as production loader tool to subsequently load code to Flash).

Regards

Mark