Porting from MSP430FR5996 to MSP430FR2355 issue

Kernel
1

nikola1010 wrote on Saturday, June 08, 2019:

Hi all,

I have tried to port MSP430FR5969 example to MSP430FR2355 and for some reason it always fails at pvPortMalloc and finishes in vApplicationMallocFailedHook.

FR23 has more RAM then FR59 so there is no reason to fail at this.

Things I did:

  1. Changed vApplicationSetupTimerInterrupt (TA0CTL to TABCTL, and all those from A->B)

  2. Changed prvSetupHardware (Configured to 1Mhz , instead of 8 in the original)

  3. Inside Leds.c configured proper ports for two leds being used.

Stepping through code I think I’ve isolated issue to prvHeapInit which running on FR5969 returns xFreeBytesRemaining with size, and running on FR2355 returns 0.

Why the hell would it ever fail in that part of code for FR23 and not for FR59, especially because this is just array ucHeap[ configTOTAL_HEAP_SIZE ], any ideas?

I have put all of it on drive and if it all comes together I will put it to github as example for others.

https://drive.google.com/open?id=1FrO5-Z4vmE16Aj9wtZo7YKmJ_-_dhorS

Could some please help out on this.
Big tnx in advance.

2

rtel wrote on Saturday, June 08, 2019:

Did you try increasing configTOTAL_HEAP_SIZE?

Which heap implementation are you using?
https://www.freertos.org/a00111.html

3

nikola1010 wrote on Saturday, June 08, 2019:

heap_4 is used.

For the size tried ( 14 * 1024 ) and (20*1024), no change.
Thing is that this code (in original form) is for uC with much lower RAM values , so this should work without any issue in that sense.

4

rtel wrote on Saturday, June 08, 2019:

Is it the first allocation that fails? If so it could be that the c startup code is not initializing the variables properly.

5

nikola1010 wrote on Saturday, June 08, 2019:

Yes it seems that first init is failing.

	/* If this is the first call to malloc then the heap will require
	initialisation to setup the list of free blocks. */
	if( pxEnd == NULL )
	{
		prvHeapInit(); <-- enters here
	}

What action could verify this condition and/or what could be done?

6

nikola1010 wrote on Saturday, June 08, 2019:

Ok it seems that setting did the trick.
The difference was that in original example static was missing.
Also had to lower TOTAL_HEAP_SIZE.

#define configAPPLICATION_ALLOCATED_HEAP 0
// Original #define configTOTAL_HEAP_SIZE ( 14 * 1024 )
#define configTOTAL_HEAP_SIZE ( 3 * 1024 )

Now issue becomes that all stops in ISR trap after ~15 seconds , and I can reproduce it , it is always ~15 seconds.

;-----------------------------------------------------------------------------
;-- default ISR handler if user does not supply
;-- simply puts device into lpm0
;-----------------------------------------------------------------------------

   	.sect	".text:_isr:__TI_ISR_TRAP"
	.align	2
	.global	__TI_ISR_TRAP
__TI_ISR_TRAP:
        BIS.W     #(0x0010),SR
        JMP __TI_ISR_TRAP

        NOP                     ; CPU40 Compatibility NOP

Could this be somehow connected?

7

rtel wrote on Saturday, June 08, 2019:

Are you using the correct linker script for the part?

8

nikola1010 wrote on Monday, June 10, 2019:

Yes I am, lnk_msp430fr2355.cmd.