MCUXpresso Debugged Code works. Bootable Image from MCUBoot/Secure Provisioning do not.

[engi_2068]

I have a program that works perfectly if! I program it from MCUXpresso using the "debug" option.

Chip is the i.MX RT1060.

However, I attempt to program it from either MCUBoot or Secure Provisioning over USB I have a section of the code that starts producing errors. I switch into USB Bootloader mode to do the programming and back for the MCUBoot/Secure Provisioning method.

The code is a SPI memory read back comparison.

What would be the best places to start looking.

I'm lost. The stages to create a bootable image seem many.

[engi_2068]

I appreciate the help.

I tried changing the XIP_BOOT_HEADER_ENALBLE to 0

and changing the BOARD_FLASH from 0x6000000 to 0x6002000.

After flashing with MCU Boot Utility with the .s19 created from the MCUXpresso .axf, the program did not run and genreated zero output.

The SPI readback function is simply a function that is reading bytes from a peripheral and checking that it responds with the same data it sent. This data lives in  a static const uint8_t [2014].

The code when run from MCUXpresso using the "Debug" option does not fail at this point and works as it should.

[kerryzhou]

Hi @engi_2068 ,

   Don't worry, this should be the small issue.

  Please help to check the following points at first.

1. Which board you are testing? NXP MIMXRT1060-EVK board?

2. Which code you are testing, SDK or your own code?

3. Your mentioned SPI readback function, do you debug the project with the debugger at first, whether that work or not?

4, I suggest you use the simple SDK project, eg, SDK led_blinky project test it at first, after it works, then you will know the correct flow.

5. Please note, the address is 0x60002000, not 0x6002000, your address is wrong.

Best Regards,

Kerry

[engi_2068]

Once again I appreciate the reply.

1. This is unfortunately a custom boards based on the 1060.

2. I am unfortunately testing my own code.

3. SPI readback from off chip peripheral works fine when I "debug" from MCUXpresso but not when I boot after doing a MCUBootUtility download. See below as to possible lead.

4. I have a project based on the same 1060 board and same SPI peripheral which does work with axf/s19 downloaded through MCUBootUtility. I have mimiced it's RAM layout and flow through MCUBootUtility exactly on this troublesome project but without results. This may be do to a conflict introcuced in new code, see possible lead below.

5. A mistype on my part.

I seem to have some kind of lead.

I have a two GPIO outputs tied to GPIO_B1_02 and GPIO_B1_03 as seen here:

which control an SPI Chip Select Mux.

In the debug MCUXpresso version I seem normal stable behavior. You can see the CH0 and CH1 cycling between 4 peripheral SPI devices whose CS lines are attached through the mux output.

However, in the axf version run through MCU Boot Utility I see unstable behavior on these pins.

So, debugging/attaching the AXF/s19 which is running after reset from the MCU BootUtility shows error on SPI reads. I can see now that unstable behavior on the CS mux select is likely the issue.

However, I only see the behavior when the axf/s19 is run through MCUBootUtility and booted. However normally when run from "Debug" inside MCUXpresso, the lines are stable.

I have also traced the behavior if I attempt to debug from MCUXpresso if I make the following changes, attempting to link the program to SDRAM.

It's almost as if something is overwriting the GPIO2/7 peripheral at random, but only if I attempt to boot the board from an AXF/S19 run through the MCUBootUtility.

I have tried multiple things already.

I've attempted to move my stack and heap from DTC to SDRAM and increase it to 1MB each. I thought I might be overflowing into the GPIO region. However all other code seems to work fine. A full Wifi stack inits and connects to a remote Python client just fine everytime. Major stack overflow seems unlikely.

I have moved the Mux Select Pins from GPIO2 to GPIO7. Another attempt to move the GPIO address to see if it prevents overwrite. However, the same behavior results.

I had previously had DMA enabled on this LPSPI, but I turned it off and removed all associated code.

My hunch now, is that somehow XIP init is causing this issue.

Any ideas or thoughts?

[engi_2068]

Okay. Even more debug.

Those flakey lines were my bad. My logic analyzer was not setup correctly. I can confirm that the data on the LINE is perfect.

Dumping the interpreted data to and from the peripheral device is perfect.

However, the data read back from the LPSPI 1060 peripheral is seemingly bad.

The .rxdata struct has the wrong data when then LSPI RTOS functions return.

static uint32_t x4driver_local_spi_write_read_one(void *user_reference, uint8_t *wdata, uint32_t wlength, uint8_t *rdata, uint32_t rlength)
{
	Hal_t *hal = user_reference;

	uint8_t rd_tmp[2] = {0, 0};

	lpspi_transfer_t xfer = {
		.txData = (uint8_t*)wdata,
		.rxData = (uint8_t*)rd_tmp,
		.dataSize = 2,
		.configFlags = X4_SPI_MASTER_PCS_FOR_TRANSFER | kLPSPI_MasterPcsContinuous | kLPSPI_MasterByteSwap
	};

	int status = LPSPI_RTOS_Transfer(&hal->spi_x4_handle, &xfer);
	*rdata = rd_tmp[1];
	return (status == kStatus_Success) ? 0 : -1;
}

So odd. That this is only happening through s19 McuBootUtility//NXP Provisioning Tool.

I am able to examine the program, as I can still attach a debugger after flashing the board with the s19 and booting it.

[kerryzhou]

Hi @engi_2068 ,

   You didn't reply me about the SDRAM.

 Do you use the SDRAM? If yes, you need to add the dcd.bin in the file.

  Do you test the normal SDK led_blinky, whether that works ok or not.

  Another way, you can remove your project SDRAM, and just test it with flash, then after your SPI works OK, you can generate the srec code and download it again, in fact, if no SDRAM, it should be totally the same.

Best Regards,

kerry

[kerryzhou]

Hi @engi_2068 ,

  I get some information: you are using external SDRAM in your own project, right?

  Then, you find your code can't work normally.

  Now, don't worry, just test the code without the SDRAM, just the simple GPIO toggle, you can use the SDK code led_blinky, and download to your own board. After it works, then we can analysis your own project.

  In fact, your debug works, OK, it means, your project is OK, you can generate the .s19 file. Please note, when you use the tool download, eg MCUBooUtility, or the MCUXPresso Secure provisional tool, the dcd file need to load it seperately, it doesn't like the IDE download it together. So, you also need to generate the related dcd.bin file, then load it to the MCUBootUtility or SPT tool, then your whole project should works if your project really have the sdram.

Wish it helps you!

Best Regards,

Kerry

[kerryzhou]

Hi @engi_2068 ,

  Don't worry, the issue is easy to resolve!

  Your app project works OK on the IDE, and then after generate the file, then add it to the SPT tool or the MCUBootUtility tool, you meet issues, right?

  to the MCUbootUtility tool

   You can refer to this app:

NXP-MCUBootUtility-3.5.0\apps\NXP_MIMXRT1060-EVK_Rev.A1\led_blinky_0x60002000.srec

When you generate the code in the MCUXpresso IDE, just need to do this operation:

Then, generate the srec file, and add it to the SPT(secure provisional tool) or the MCUbootUtility again, it should works.

As the tool will help you add the FCB header.

About the code, I suggest you use the SDK code at first.

About the  SPI memory read back comparison code, how do you read the memory? Use the code run in the flexSPI flash? As the chip can't support the RWW, you need to copy the flash operation code to the internal RAM.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Best Regards,

kerry