Support for Maxim 32665 Cortex-M4

Kernel
1

The latest Maxim SDK demonstrates operation with quite old version of FreeRTOS (8.x), which is too old for us to use with CMSIS. I’ve downloaded 10.4.1 and I see that Maxim is not listed in the supported devices. No word from Maxim yet as to whether anyone is updating for the latest and greatest. Does anyone have a recommendation for where to check for a working example project for this family?

1 Like
2

Basically it’s a Cortex-M4 so any CM3/CM4F demo is fine.
On the other hand you could also drop-in replace the legacy FreeRTOS 8.x with 10.4.x in your MaximSDK demo. It should be backwards compatible.
You can make use of newer features later on / step by step.

3

Right - the FreeRTOS Cortex-M ports have no dependency on anything other than the Cortex-M core itself. As all Cortex-M cores are the same the FreeRTOS port files will work on any Cortex-M part.

4

Based on this thread, I tried to update to a newer FreeRTOS distribution and it did not work. I get a BFAR right out of the start of the scheduler. (Same chipset as the topic states)

Is there anything I need to do? The replies here make it seem as though it is drop in replacement.

TIA ~Mike

5

How many interrupts does your pod support? you may need to make adjustments there.

1 Like
6

That is a great question. i will make that comparison in the morning.

Thank you for the tip.

Mike

7

Also, it will be helpful if you can share the instruction causing bus fault and the callstack at that point too.

Thanks.

8

So I experienced major problem with the Maxim 32625 with their FreeRTOSDemo. I started with the example and added a second UART and implemented a few GPIO interrupts to signal my thread. I had an unexplained hard fault at random time. Solution

  1. [Optional but highly recommended] Add this line to FreeRTOCConfig.h
    #define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}
    This was NOT defined and if it was then their demo would have failed.
  2. Actually fix in FreeRTOCConfig.h
    Change
    #define configMAX_SYSCALL_INTERRUPT_PRIORITY ( ( unsigned char ) 5 << ( 8 - configPRIO_BITS) )

to
#define #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 1
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( ( unsigned char ) configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << ( 8 - configPRIO_BITS) )

Then in your source files like pb.c use configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY with the NVIC_SetPriority.
NVIC_SetPriority(MXC_GPIO_GET_IRQ(pb_pin[pb].port), configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY);

The actual problem occurred in portmacro.h in vPortRaiseBASEPRI() because depending on when my UART IRQ at level 1 and GPIO (level not set in example code) occurred, the BASEPRI is set to value too large. The configASSERT() catches this problem.

If you want some IRQ not at same priority, then NVIC_SetPriority can just configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY+1.

So configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY can be >1 which is fine so long as your IRQ processes at 1 does not make any FreeRTOS calls. If it does, then the check done with vPortValidateInterruptPriority() will ASSERT the code.

Hope this save you the 1.5 weeks of time when I was it was my stack or heap or thread contention with UART async processing.

9

Thanks for the info - have you reported this to Maxim (or whoever provided the demo)? Here is a good reference for readers: RTOS for ARM Cortex-M