Page 1 of 1

Test project to attempt to debug the problem with the new CPU

Posted: Thu Feb 16, 2023 5:05 am
by VK3KYY
Anyone who wants to have a go at working out why the CPU in the new radios does not work....

I have made a "test" project which has the minimal code necessary to test and debug the problem

See

https://github.com/LibreDMR/MDUV380_Testbed

In order to build the test firmware, you need to download and install STM32CubeIDE from STM (requires registration even though its free)
https://www.st.com/en/development-tools ... beide.html

Once installed, you need to import the project files

In STM32CubeIDE you will need to use File -> Import -> Projects from Folder or Archive

Select the folder containing the project files

Then wait for STMCube to download all the necessary other files it needs


The crash seems to occur when the FreeRTOS scheduler is started

https://github.com/LibreDMR/MDUV380_Tes ... 1977-L2103


The firmware does not seem to reach the part of the code intended to handle errors
https://github.com/LibreDMR/MDUV380_Tes ... 2090-L2093


I've also added code into the void HardFault_Handler(void) etc but the code does not appear to crash there either

Re: Test project to attempt to debug the problem with the new CPU

Posted: Thu Feb 16, 2023 5:37 pm
by VE2NCK
after a few tries, i'm stuck in tasks.c
configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

which point me in FreeRTOSConfig.h
to this
#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}

Re: Test project to attempt to debug the problem with the new CPU

Posted: Thu Feb 16, 2023 7:03 pm
by G4EML
My understanding is that configASSERT(x) is used to check that the value x is non zero (true).

If x is zero (false) then the code will disable interrupts and enter an infinite loop. Effectively halting.
if x is non-zero (true) then it will do nothing and will continue with the next statement.

Colin.

Re: Test project to attempt to debug the problem with the new CPU

Posted: Thu Feb 16, 2023 8:23 pm
by VK3KYY
Where is this line of code?



The error aopoesrs to be that it fails to allocate some memory

I think the CPU has 3 separate RAM sections, but I don't know which section FreeRTOS would use.

We use the default settings in STM32Cube for FreeRTOS

Re: Test project to attempt to debug the problem with the new CPU

Posted: Thu Feb 16, 2023 9:20 pm
by VK3KYY
VE2NCK wrote:
Thu Feb 16, 2023 5:37 pm
after a few tries, i'm stuck in tasks.c
configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

which point me in FreeRTOSConfig.h
to this
#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}
If you are saying that its stuck at

Code: Select all

	configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );
Then it should be disiplaying the message "configASSERT" on the screen, because the code in that else{} block has this code (which I added)

Code: Select all

	  	displayPrintCentered(48,"configASSERT", FONT_SIZE_2);
	  	displayRender();
	  	nonOSDelay(2000);

Do you see the configASSERT message on the screen

Re: Test project to attempt to debug the problem with the new CPU

Posted: Fri Feb 17, 2023 2:02 am
by VE2NCK
VK3KYY wrote:
Thu Feb 16, 2023 9:20 pm
VE2NCK wrote:
Thu Feb 16, 2023 5:37 pm
after a few tries, i'm stuck in tasks.c
configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );

which point me in FreeRTOSConfig.h
to this
#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}
If you are saying that its stuck at

Code: Select all

	configASSERT( xReturn != errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY );
Then it should be disiplaying the message "configASSERT" on the screen, because the code in that else{} block has this code (which I added)

Code: Select all

	  	displayPrintCentered(48,"configASSERT", FONT_SIZE_2);
	  	displayRender();
	  	nonOSDelay(2000);

Do you see the configASSERT message on the screen
no i don't see it

Re: Test project to attempt to debug the problem with the new CPU

Posted: Fri Feb 17, 2023 3:42 am
by VK3KYY
OK. So it may never be leaving xTaskCreate