Erratic behaviour of i.MX RT1064

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Erratic behaviour of i.MX RT1064

Jump to solution
930 Views
h_bouchard
Contributor III

Hello,

We have developed a board + software that works fine on a i.MX RT1064. We then decided to reduce the number of options so we redesigned the board to remove the Ethernet and WiFi. The pinout remains the same (except for the function removed) and therefore the software is also very similar without the functionality removed.

The "funny" thing is that the new software works on the old board but does not on the new board. The behaviour is erratic. I can flash the new board but I can't step over the code. When I click on the step over button, the application keep running and when I pause it again, it is executing some code in ROMCP (0x0020xxxx). I get the same result if I click the play button and pause the application.

If I click on the step into button, it's executing the code but in the example below, it would step into CLOCK_EnableClock(kCLOCK_Iomuxc) function but when this function returns, the PC is back at the beginning of the function and function CLOCK_EnableClock(kCLOCK_Iomuxc) is called again over and over.

void BOARD_InitGPIO(void) {
  CLOCK_EnableClock(kCLOCK_Iomuxc);

  /* GPIO configuration of LED1_STATUS on GPIO_AD_B0_13 (pin L14) */
  gpio_pin_config_t LED1_STATUS_config = {
      .direction = kGPIO_DigitalInput,
      .outputLogic = 0U,
      .interruptMode = kGPIO_NoIntmode
  };
  /* Initialize GPIO functionality on GPIO_AD_B0_13 (pin L14) */
  GPIO_PinInit(GPIO1, 13U, &LED1_STATUS_config);
(...)

 
The only thing that seems to work it the run to cursor option but it's not quite it. When I create a task (FreeRTOS), it is not able to allocate the stack memory even though the heap (heap4.c) is of 40kB and it is empty at that point.

The hardware is almost identical. The only difference is the power supply chip that create the 3.3V and the 1.8V. This behaviour is very strange. Does anyone has an idea of what this problem could be?

Thanks for your help
Hugo

Labels (1)
0 Kudos
1 Solution
924 Views
h_bouchard
Contributor III

Ok we found the solution...

The boot pins were pulled down and the efuse were not programmed therefore the chip was not booting properly. However I'm wondering why it wasn't working in debug mode with a JLink plugged in but anyways, now it's working.

Hugo

View solution in original post

0 Kudos
1 Reply
925 Views
h_bouchard
Contributor III

Ok we found the solution...

The boot pins were pulled down and the efuse were not programmed therefore the chip was not booting properly. However I'm wondering why it wasn't working in debug mode with a JLink plugged in but anyways, now it's working.

Hugo

0 Kudos