EasyEVSE EV Charging Station Development Platform Bug

[MulattoKid]

Hi,

We have been using the Azure ThreadX OSAL provided in the EasyEVSE EV Charging Station Development Platform demo, and recently discovered a bug in the OSAL. Specifically in phOsal/src/Azurertos/phOsal_Azurertos.c:90 (but also 73 and 79).

73: status = tx_event_flags_get(&pointer,FlagsToClear, TX_AND_CLEAR, (ULONG *) &pCurrFlags, 0);

79: status = tx_event_flags_get(&pointer,FlagsToClear, TX_AND_CLEAR, (ULONG *) &pCurrFlags, 0);

90: status = tx_event_flags_get(&pointer,FlagsToWait, TX_OR, (ULONG *) &pCurrFlags, ticksToWait);

All of these take the address of pCurrFlags, which already is a pointer. tx_event_flags_get will then dereference the pointer and write to it. In our case 0x0 was written. Afterwards, in the case of line 90, the pointer is dereferenced again to compare its value against FlagsToWait. This leads to a "null-pointer" dereference.

In our code this has "worked" for quite some time, until we recently decided to reconfigure our FlexRAM to:

- 0KiB OCRAM

- 512KiB DTCM

- 0KiB ITCM

ITCM (which starts at 0x00000000) is no longer accessible, and we get a HardFault. Before, address 0x00000000 was valid, and the access in the OSAL succeeded, even though it was logically invalid.

The fix looks like this:

73: status = tx_event_flags_get(&pointer,FlagsToClear, TX_AND_CLEAR, (ULONG *) pCurrFlags, 0);

79: status = tx_event_flags_get(&pointer,FlagsToClear, TX_AND_CLEAR, (ULONG *) pCurrFlags, 0);

90: status = tx_event_flags_get(&pointer,FlagsToWait, TX_OR, (ULONG *) pCurrFlags, ticksToWait);

[Gavin_Jia]

Hi @MulattoKid ,

Thanks for your interest in NXP MIMXRT series!

Thanks for the suggestion, I agree with what you said about this issue and as well as submitted it to the internal team for review.

I will update here once I receive a confirmed response.

Best regards,
Gavin

[Gavin_Jia]

Hi @MulattoKid ,

Thanks for your patience.

According to what I'm getting from the inside, the team needs more information to verify. Could you check these for me? Thanks in advance!

1. Please check the link file, and please make sure that no-body will use the memory from 0x0.

2. And checking the configuration of the MPU, in this case, the 0x20000000 shouble be a size of 512KB, and the others are 0.

3. Or you can attach the project or the link file + mpu.c, our colleagues will check it.

Best regards,
Gavin

[MulattoKid]

Hi @Gavin_Jia,

This is an excerpt from our linker file, showing how we've configured the FlexRAM:

m_ocram                 (RX)  : ORIGIN = 0x20280000, LENGTH = 0x00000000 /* 0KiB */
m_ocram2                (RX)  : ORIGIN = 0x20200000, LENGTH = 0x00080000 /* 512KiB */
m_dtcm                  (RW)  : ORIGIN = 0x20000000 + STACK_SIZE, LENGTH = 0x00080000 - STACK_SIZE /* 512KiB - (Stack Size) */
m_dtcm_stack            (RW)  : ORIGIN = 0x20000000, LENGTH = STACK_SIZE /* (Stack Size) */
m_itcm                  (RW)  : ORIGIN = 0x00000000, LENGTH = 0x00000000 /* 0KiB */

However, this isn't really important for the bug, but we only discovered the bug upon changing our FlexRAM configuration to not have any banks allocated to ITCM.

The actual bug is in the OSAL layer (phOsal/src/Azurertos/phOsal_Azurertos.c:73, 79 and 90), where a double pointer is passed to a place that expects a pointer. pCurrFlags is already a pointer, and doesn't need to have its address taken when passed to tx_event_flags_get:

73: status = tx_event_flags_get(&pointer,FlagsToClear, TX_AND_CLEAR, (ULONG *) &pCurrFlags, 0);
79: status = tx_event_flags_get(&pointer,FlagsToClear, TX_AND_CLEAR, (ULONG *) &pCurrFlags, 0);
90: status = tx_event_flags_get(&pointer,FlagsToWait, TX_OR, (ULONG *) &pCurrFlags, ticksToWait);

This is wrong regardless of the FlexRAM configuration.