I meet an issue on writing Flex RAM on MK10DX256VLL7.

[wentong]

I was using CodeWarrior10.6 to debug, the program is stuck at:

00006682:   add r1,r6,#0x14000000

130               *(U8*)(FLEX_EE_BASE_ADDRESS + address + i) = buf[i];

00006686:   strb r2,[r1,r5]   <--Stuck here, can't move forward, even in instruction step mode.

131               HAL_FlexEE_wait();

00006688:   bl HAL_FlexEE_wait (0x69a4); 0x000069a4

Register values:

R0    0x00000001    $R0   

R1    0x1400000d    $R1   

R2    0x000000fe    $R2   

R3    0x0000000f    $R3   

R4    0x00000002    $R4   

R5    0x00000001    $R5   

This thread returns error:

pthread: 0x00010007	0x10007	0x1ffff06c	89	0x0000042b	Unknown error (0x0000)
pthread: 0x00010008	0x10008	0x1ffffdac	87	Active	Unknown error (0xffffffff)	(this thread)
pthread: 0x00010009	0x10009	0x1ffffebc	72	Time delay blocked	Unknown error (0x0000)
pthread: 0x0001000A	0x1000a	0x200026f0	84	0x0000042b	Unknown error (0x0000)
pthread: 0x0001000B	0x1000b	0x20003740	83	0x0000042b	Unknown error (0x0000)
pthread: 0x0001000C	0x1000c	0x20004a20	81	0x0000042b	Unknown error (0x0000)
pthread: 0x0001000D	0x1000d	0x200059a0	79	0x0000052b, timeout   Unknown error (0x042a)
pthread: 0x0001000E	0x1000e	0x20006920	80	0x0000042b	Unknown error (0x0000)

The tricky part is the previous versions of my code can work correctly, but the new version run into this issue. I don't see any changes related with flex ram.

Can anyone help me on this? thanks.

[wentong · Accepted solution]

This issue is fixed by following changes to HAL_FlexEE_wait:

bool HAL_FlexEE_wait(void)

{

#if 0

    MQX_FILE_PTR         flash_fd;

    S32                     error_code;

    bool                 ret_val = true;

    /* Open the flash device */

    flash_fd = fopen(FLASH_DEVICE, NULL);

    if (NULL == flash_fd)

    {

        return false;

    }

    /* wait for FlexEEPROM ready*/

    error_code = _io_ioctl(flash_fd, FLEXNVM_IOCTL_WAIT_EERDY, NULL);

    if (IO_OK != error_code)

    {

      ret_val = false;

    }

    fclose(flash_fd);

    return (ret_val);

#else

    while (!(FTFL_FCNFG_REG(FTFL_BASE_PTR) & FTFL_FCNFG_EEERDY_MASK)){}

    return true;

#endif

}

[wentong]

Code:

for ( i = 0; i < bufLen; i++ )

    {

	*(U8*)(FLEX_EE_BASE_ADDRESS + address + i) = buf[i];
	HAL_FlexEE_wait();

    }

Further debug shows the first byte has been writen into the EEPROM, i can use CW to read from memory and see the first byte changed, but blocked at writing the second byte. I suspect the HAL_FlexEE_wait() is the blocking point and replace with a "dead loop" delay, same thing. Still blocking at strb r2,[r1,r5].

[Jorge_Gonzalez]

Hello wen tong:

That issue is strange. Please check my questions below:

- I guess you have the FlexNVM partitioned and configured to be used as EEPROM. Is that correct?

- What software framework or drivers are you using? I did not recognize the HAL_FlexEE_wait() or the FLEX_EE_BASE_ADDRESS.

- Do you have any compiler/linker optimizations enabled?

- If possible please share the complete code or project. If I can reproduce the issue it is much easier to find the cause.

Regards!

Jorge Gonzalez

[wentong]

Thank you Jorge for the response.

My answers for your questions below:

-Yes i have the FlexNVM partitioned:

      /* read partition code to check FlexNVM settings */

      error_code = _io_ioctl(flash_fd, FLEXNVM_IOCTL_GET_PARTITION_CODE, &part_param);

      if (IO_OK != error_code)

      {

          fclose(flash_fd);

          return false;

      }

      /* check FlexNVM partition settings */

      if (FLEXNVM_PART_CODE_NOPART == part_param.FLEXNVM_PART_CODE) {

          //nEnabling FlexEEPROM - partition memory

          /* set FlexNVM partition and EEPROM size */

          /**

           * EEESIZE - Table 28-67. Valid EEPROM Data Set Size Codes

           * '0111' = 128 Bytes - (Endurance time: 600,000 ~ 1,000,000)

           * DEPART - Table 28-68. Valid FlexNVM Partition Codes

           * 1000 = No data flash, 32 Kbytes of EEPROM backup

           */         

          part_param.EE_DATA_SIZE_CODE = 0x37;

          part_param.FLEXNVM_PART_CODE = 0x08;

          _io_ioctl(flash_fd, FLEXNVM_IOCTL_SET_PARTITION_CODE, &part_param);        

          /* switch FlexRAM to EEPROM mode */

          flexRAMCode = FLEXNVM_FLEXRAM_EE;

          _io_ioctl(flash_fd, FLEXNVM_IOCTL_SET_FLEXRAM_FN, &flexRAMCode);

      }

- I'm using MQX4.1. HAL_FlexEE_wait is using ioctl command FLEXNVM_IOCTL_WAIT_EERDY and FLEX_EE_BASE_ADDRESS is 0x14000000.

- I'm using arm-none-eabi-gcc-4_7_3 compiler and with -Os optimization, and i have tried -O0 and it has the same issue.

- Sorry i can't share the complete code due to the company rules except the fragment related with this issue.

This issue happens in some of the code versions, and the code changes seems no connection with EEPROM. Any other possibility could lead to Flex RAM writing blocked?

[Jorge_Gonzalez]

Hello wen tong:

It is hard to say what is going wrong in your case without being able to reproduce it.

Now the MQX Flashx driver uses some structures and pointers, so you need to check that those are not getting corrupted by any change made to the project. For example the driver waits for the EEERDY bit in the FTFL_FCNFG register to be set, but this is made with a pointer which must be pointing to that specific register. Debugging at the assembly level like you seem to be doing is also a good idea.

You mention in your post that the program is "stuck". What exactly do you mean with "stuck"?

Usually when something goes wrong at the MCU Core level the execution should go to a hardfault, busfault, runaway execution, device reset, etc. The exceptions might be a defective clock configuration (e.g. overclocking the core/bus or the flash memory), unstable or out-of-range power supply. The Flash clock is particularly important, you need to make sure that it does not exceed 25 MHz for your device and that the bus clock is equal or higher than the flash clock.

Let us know of any more symptoms you see or details about the changes between code versions so we can try to isolate the issue.

Regards!

Jorge Gonzalez

[wentong]

Jorge i understand it's hard for you to help if you can't reproduce this issue, but thank you for all of the reminders.

The "stuck" i mean comes from the situation i saw from the CW IDE, when i run the code, and pause it, run it and pause it again, it just stops there. I was curious about why it can't move forward to next assembly instruction.

I would deal with some other tasks before i come back to this issue again. I will update this topic if have new findings. Thanks.