Enabling TraceX in my NetXDuo application causes `_nx_trace_event_insert' compile errors.

[MHoop.1]

I am attempting to use TraceX in my NetXDuo application. But when I enable TraceX in the Software Packs of CubeIDE (TX_ENABLE_EVENT_TRACE) I get compiler errors in all of the calls to save a tracex event. The macros that defines the calls to tracex services appear in nx_api.h, but are not defined, and hence the _nx_trace_event_ service is never defined.

 

 

I saw a discussion of this same issue over in the Renesis community where a workaound fixed the compiler issue.

https://community.renesas.com/mcu-mpu/embedded-system-platform/f/forum/10314/undefined-reference-to-nx_trace_in_line_insert-when-arp-probe

But t his workaround did not fix the STM code.

Can anyone suggest something that may help?

Thanks,

MikeH

[STM32_ZA]

Hi MikeH,

I haven't reproduced your issue can you please provide more details on:

• STM32 device
• X-CUBE-AZRTOS version

By the way can you check that the NetXDuo trace files (nx_trace_*) are added to your project when enabling TraceX support

Regards

[MHoop.1]

ZA,

Device STM32F723ZGTx

Board: NUCLEO-H723ZG

X-CUBE-AZRTOS Versions

My program is based off of the Nx_TCP_Echo_Server example. I have added additional user code which forwards commands received from a TCP client to USART2. The response received from the USART is then forwarded back to the client. This all works as expected, except that occasionally the network connection is dropped. I need to use TraceX to debug this issue.

By the way can you check that the NetXDuo trace files (nx_trace_*) are added to your project when enabling TraceX support

I don't see any nx_trace_ code inserted into main.c, app_nextduo.c, or app_azure_rtos.c. I manually inserted the following into app_threadx.c per the training video.

TX_THREAD thread_ptr;
#define TRACEX_BUFFER_SIZE 64000
uint8_t tracex_buffer[64000] __attribute__ ((section (".trace")));
/* USER CODE END PV */
 
...and
 tx_trace_enable(&tracex_buffer,TRACEX_BUFFER_SIZE,30);
 /* USER CODE END App_ThreadX_Init */

Thanks for the help.

MikeH

[STM32_ZA]

Hi,

Can you try with X-CUBE-AZRTOS-H7 V3.0.0

I attached an ioc file created with STM32CubeMX 6.7.0 and X-CUBE-AZRTOS-H7 V3.0.0 that helps you to enable the TraceX support for NetXDuo :

[MHoop.1]

Thanks Zouhair. I'll give this a try over the next few days and report back.

I did install V3.0 X-CUBE-AZRTOS-H7 and now see the TraceX support files as shown in your screenshot.

Thanks,

MikeH

[MHoop.1]

Zouhair,

I was able to get your sample code working and was able to capture TraceX data and view it in the TraceX app. Thanks for that.

However, I did run into several issue when trying to incorporate TraceX into my application (based on the NX_TCP_Echo_Server example code).

• I ran out of byte_pool memory when allocating all of the services in my NetxDuo application. I tried increasing the memory available for allocation of byte_pool by increasing the NetXDuo memory pool size. But when I attempted to allocate greater than 0x8100 bytes, I got a hard fault. Something in the allocation code (tx_byte_pool_search.c?) seems to crash beyond 0x8100 bytes.
• The code below causes the hard fault.

#define NX_APP_MEM_POOL_SIZE 0x8200

• CubeIDE doesn't always save a manually change value for NetXDuo memory pool size when it is changed in the CubeIDE GUI , even after Code Generation. You can see the unchanged value in app_azure_rtos_config.h, but the GUI shows the new value.
• Your sample project did not include any BSP support code. I had to manually copy the code over from another project. This was manually intensive since I had to relink several paths, as well as other changes. Is there an easy way to add BSP support (i.e. NUCLEO-H723) to a generic .ioc project like the one you sent me?

Thanks again for your help.

Mikeh

[STM32_ZA]

Please find below my comments/answers:

1-I ran out of byte_pool memory when allocating all of the services in my NetxDuo application.

As mentioned in readme file some changes are required when changing the NX_PACKET pool size or address. The NX_PACKET start address (0x24048000) used in this example allows only pool size < 32KB so you you need to set/update start address as follows:

• STM32H723ZGTX_FLASH.ld.file

   .tcp_sec (NOLOAD) : {

  . = ABSOLUTE(0x24030000);

  *(.RxDecripSection)

  . = ABSOLUTE(0x24030060);

  *(.TxDecripSection)

 } >RAM_D1 AT> FLASH

.nx_data 0x24030200 (NOLOAD):

 {

  *(.NetXPoolSection)

 } >RAM_D1 AT >FLASH

• main.c file:

 MPU_InitStruct.Number = MPU_REGION_NUMBER1;

 MPU_InitStruct.BaseAddress = 0x24030000;

 MPU_InitStruct.Size = MPU_REGION_SIZE_64KB;

 MPU_InitStruct.SubRegionDisable = 0x0;

 MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

 MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

 MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;

 MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;

2.CubeIDE doesn't always save a manually change value for NetXDuo memory pool size when it is changed in the CubeIDE GUI , even after Code Generation

Do you have same behavior with STM32CubeMX 6.7.0 ?

3-Your sample project did not include any BSP support code

BSP support is not managed by X-CUBE-AZRTOS and BSP files should be added manually by user or using .extSettings file which allows to add paths and files to project:

• create or copy an existing .extSettings file at example root folder: You can find example here : Projects\STM32H735G-DK\Applications\USBX\Ux_Host_MSC\.extSettings
• Update .extSettings
• Generate project

[ProjectFiles]

HeaderPath=..\..\..\..\..\..\Drivers\BSP\STM32H7xx_Nucleo

[Others]

HALModule=

[Groups]

Drivers/BSP/STM32H7xx_Nucleo=../../../../../../Drivers/BSP/STM32H7xx_Nucleo/stm32h7xx_nucleo.c;

[MHoop.1]

Zuhair,

Thanks so much for your continued assistance.

I made the memory allocation modifications that you recommended. But I still get a Hard Fault when the byte_pool allocation attempts to allocate greater that 32kbytes.

Here is what I modified.

• I modified the STM32H723ZGTX_FLASH.ld.file per your recommendations above.
• I modified the .ioc GUI as below (code gets modified during code-regeneration if modified directly in main.c)

 

• When attempting to execute tx_byte_allocate as the byte_pool exceeds 32kbyte, I get a hard fault at this statement.

/* Allocate the memory for TCP server thread */
 if (tx_byte_allocate(byte_pool, (VOID **) &pointer,2 * DEFAULT_MEMORY_SIZE, TX_NO_WAIT) != TX_SUCCESS)

• The byte_pool->tx_byte_pool_search value is 0x24037b88 which is just below 32kbytes. During this allocation is when the hard fault is thrown.
• And here is the build analyzer showing the allocations. Is the order correct?

Could there be some other setting that limits the allocated memory to 32kbytes?

thx

MikeH

[STM32_ZA]

can you share your example if it's possible ?

[MHoop.1]

Do you have an email address that I could send it to?

[MHoop.1]

It appears that the example code that I had used as the basis of this application was faulty. (It was apparently from an early CubeIDE example). I completely rebuilt the application using the Nucleo-H723 Nx_TCP_Echo_Server application from the Git download.

https://github.com/STMicroelectronics/x-cube-azrtos-h7

After help from Zuhair, and a LOT of watching the Workshops...

https://www.youtube.com/playlist?list=PLnMKNibPkDnGxMITHhhRqbT0-2egHq0D0

...I was able to configure the example to work properly and to generate TraceX functionality!

This is a very lengthy process due to the MANY modifications that must be made to the examples provided by ST. I highly recommend that ST provide a "ready-to-run" version of these examples so that you don't loose developers who don't have the time or patience to spend plugging through the (partial) details provided by the (very well done) workshops.

In summary, I now have TraceX working on a TCP Server application on a Nucleo H723 board. I find TraceX to be marginally helpful due to its clunky GUI and somewhat limited functionality. Hopefully it will help me debug the issues that I now have with network reliability and stability.

Thanks again Zuhair for your guidance!

MikeH