MCUXpresso Secure Profisioning flashloading fails

[MKlem]

Best, 

I am running a custom board with an i.MX RT1011 with the USB port connected to my PC. I'am trying to update the firmware using the onboard bootloader.

When jumping to the bootloader, the USB enumeration works and MCUXpresso Secure Provisioning recognizes the board:

When pressing OK the image can be build: 

However, when going to the "Write image" tab and pressing the Write image button, it first succeeds loading the flashloader image. However when blhost is used to flash the image, it fails: 

### Parse input arguments ###
### Check presence of FlashLoader ###
### Configure FlexSPI NOR memory using options on address 0x2000 ###
blhost -t 5000 -u 0x15A2,0x0073 -j -- fill-memory 0x2000 4 0xC0000007 word
ERROR:spsdk.mboot.interfaces.usb:Cannot read from HID device, error=-1 (435ms since start, usb.py:242)
{
"command": "fill-memory",
"response": [],
"status": {
"description": "10004 (0x2714) No response packet from target device.",
"value": 10004
}
}
blhost failed

and the Windows USB disconnected sound plays. 

Now before the application jumps to the bootloader a couple thing happen:

- GPIO pins are initialised 

- Clocks are initialised

- I2C is initialised and EEPROM register is read (with a flag whether to jump to the bootloader)

Might that have something to do with this issue? Perhaps the FlexSPI module that is already being initialised?

Thanks for your reply!

Marcel 

[MKlem]

I just verified that it works when pulling GPIO_SD_03 low to force the RT to boot into serial downloader.

So there must be a difference when booting after the application initialisations and when booting from bootmode. 

I'll dive further into it

Marcel

[MKlem]

Hello, 

I might have find what is causing my problem. 

My application uses the FlexRAM module to change the internal RAM to 64kb OCRAM 64kb DTCM 0kb ITCM

And with the debugger connected, I verified that this configuration sticks when jumping to the SDP. This might cause the bootloader to... undefined behaviour? 

Is it possible to change the RAM segments back at runtime right before jumping into the bootloader? Or is that not possible? I am reading AN12077 but it's quite an intensive document to read. 

Thanks! 

Marcel

[MKlem · Accepted solution]

Winner winner chicken dinner!

I've managed to trace what the bootloader does and by writing the argument (0xeb100000) directly to a specific register no RAM is required. After that the NVIC_SystemReset is called. 

This seems to work. For others; my runBootloader function looks like this:

static void runBootloader(void * arg) {
	//Reset flex ram for bootloader
	FLEXRAM->TCM_CTRL &= ~4;
	//Set size for DTCM and ITCM to defaults of 32kb 
	IOMUXC_GPR->GPR14 = (0x6<<20);
	IOMUXC_GPR->GPR14 |= (0x6<<16);
	//Tell flexRAM bank0 = O, bank1 = O, bank2 = D bank3 = I
	IOMUXC_GPR->GPR17 = 0xE5;
	//Make sure the xTCM memories are intialised by setting the following bits
	IOMUXC_GPR->GPR16 |= 0x7;
        
        //g_bootloaderTree->runBootloader(0xeb100000);
        //Because the stack (RAM) might be invalid, write the argument directly to the address the call would otherwise do
	uint32_t *reg_to_write = ((uint32_t *)0x400F802C);
	*reg_to_write = 0xEB100000;
	NVIC_SystemReset();
}

Goodluck,

Marcel