PC when running Zephyr code

[Shruuts]

Hello,

I am using a Zephyr example that prints "Hello world" on UART1. I added blinking the LED to this code. I can get this running on the MIMXRT1060-EVKB. It uses external SPI flash which is at address 0x60000000. I program this hex file using JTAG and I am monitoring the PC and CycleCnt and they seem to be behaving normally (PC = 60002DEA, CycleCnt = F630B9B9).
I changed the blinking LED to toggling a GPIO (GPIO_AD_B1_03) which is available to probe in both EVKB and our product board configuration, and tested this code on the EVKB.
I am flashing this exact code on our new board. The new board also has an external SPI flash at address 0x60000000. I am programming it exactly the same way as the EVKB. When I look at the PC, the CycleCnt is actually running but the PC is off (PC = 0020ED48, CycleCnt = 9661031E) and hence the code does not do anything.

I have also tried flashing a circuit python hex to this new board and a regular bare-metal example. The flashing works and when I halt the MCU, the PC values seem like what it should be (PC = 60007E36, CycleCnt = DFDEC1A7). Using circuit python I am able to toggle GPIO_AD_B1_03, so I know it is not grounded.

When looking at JLinkFlashLite API, the circuitpython code is as follows:
Selected file: circuitpython_p1_0809.hex
Data file contains 3 memory ranges:
#0: 0x60000000 - 0x600001FF (512 Bytes)
#1: 0x60001000 - 0x6000102F (48 Bytes)
#2: 0x6000C000 - 0x6009958F (578960 Bytes)

The bare-metal example looks like:
Selected file: enet_txrx_transfer.hex
Data file contains 3 memory ranges:
#0: 0x60000000 - 0x600001FF (512 Bytes)
#1: 0x60001000 - 0x6000102F (48 Bytes)
#2: 0x60002000 - 0x6000B69F (38560 Bytes)

And the firmware file from PIO looks like:
Selected file: /home/shruti/Downloads/zephyr-get-started/firmware.hex
Data file contains 1 memory range:
#0: 0x60000000 - 0x60007C49 (31818 Bytes)

Any ideas what could potentially be happening? Again, I can run the code just fine on the EVKB board. Is there an extra configuration I have to do on a chip that is not on an evaluation board?

The registers are as follows on the evaluation board:
PC = 60002DEA, CycleCnt = F630B9B9
R0 = 00000000, R1 = 00000000, R2 = 00000010, R3 = 00000000
R4 = 60005BFB, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 0D050F05
SP(R13)= 800010F0, MSP= 80001940, PSP= 800010F0, R14(LR) = 60005C11
XPSR = 41000000: APSR = nZcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 02000001, CONTROL = 02, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 01

The registers are as follows on our product board:
PC = 0021AA50, CycleCnt = CA1B7FA2
R0 = 2020533C, R1 = 00000000, R2 = 00000001, R3 = 00000000
R4 = 20203A70, R5 = 401F4460, R6 = 401F4470, R7 = 401F4400
R8 = 00000001, R9 = 0BCCF039, R10= 00000000, R11= 400F8000
R12= 00000004
SP(R13)= 20200FA0, MSP= 20200FA0, PSP= 00000000, R14(LR) = 002173AF
XPSR = 41000000: APSR = nZcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00

[Shruuts]

One clue I found is that our SPI flash device is different from the default. The dev kit uses IS25WP064. Our new board uses GD25Q64E. Most things remain the same between the two, but my guess is 'jedec-id' will be different. I changed the jedec-id to the Gigadevice one (0xC8 0x40 0x17), but there was no difference in the hex file generated and this code still works on the evaluation board.

[Shruuts]

Turns out the problem was external/internal RAM. There is an external RAM present in the dev kit which is not there in our board.

[DerekSnell]

Hi @Shruuts ,
Yes, many of the i.MX RT1xxx EVKs include external SDRAM, and on those boards, the default location for the application data is in the SDRAM. For the devicetree of your custom board, you will want to move the zephyr,sram chosen node to the internal dtcm or ocram.

Also, these MCUs have a boot ROM with a Device Configuration Data (DCD) option. And these EVKs with the SDRAM will include a DCD in the Zephyr application image. The main reason for including the DCD like this is to have the boot ROM initialize the SEMC memory interface and the external SDRAM, so the Zephyr application can access the SDRAM at the start of execution. If your custom board does not include external SDRAM, then this DCD should not be included in your build (or if you want a DCD with your board, it should be modified to not initialize the SEMC and SDRAM). When cloning the EVK's CMakeLists.txt file for your board, you can remove the inclusion of dcd.c. And you can remove defining the macro XIP_BOOT_HEADER_DCD_ENABLE=1.

Best regards