Netx / ThreadX / Compiler issue - BUG?

[matt-crc]

Hello,

I started a blank project for the STM32H743 with AzRtos, ThreadX, NetXDuo..  There is something weird with the compiler and linker, or I don't understand how to setup the project...

The project compiles and runs, but the memory mapping seems to be all over the place, and I can't figure out why.

There are 2 RAM sections that I want to use... RAM_D1 (axi-ram) and RAM_D2 (SRAM1).  These are the current locations/size:

So, I want all the data, stack, variables to go into RAM_D1 (@2400_0000) and only the ethernet Descriptors and DataPool in (@3000_0000).

In the ethernet configuration, I setup the memory addresses as follows:

Note: it seems the RxBuffers Address is not used anywhere (correct me if I'm wrong, but I searched everywhere in the code and could not find it being used).  Anyway, the Ethernet descriptors were put at 0x3000_0000, and 0x3000_0060. 

Under AzureTROS settings, I allocated 40k to the NetXDuo memory pool

In the Flash.Id file I made these entries:

.eth_sec 0x30000000 (NOLOAD) :

{

/* 4 x 96 ETH */

. = ABSOLUTE(0x30000000);

*(.RxDescripSection)

/* 4 x 96 ETH */

. = ABSOLUTE(0x30000060);

*(.TxDescripSection)

} >RAM_D2 AT >FLASH

.nx_data 0x30000100 (NOLOAD):

{

. = ABSOLUTE(0x30010000);

*(.NetXPoolSection)

} >RAM_D2 AT >FLASH

Now, I thought it compiled correctly - the way I wanted, because when I checked the detailed memory map,

.eth_sec and .nx_data were at the correct locations and have the correct size:

The project compiles and runs, but it gets a glitch sometimes (ie ping stops responding, and then it starts again).

Then I noticed some weird things with AzRtos, it is putting the stack in RAM_D2 instead of where I expected (RAM_D1).  Any I have no idea how to fix this....

When debugging, I displayed the ThreadX list, and the 2 NetxDuo thread stacks are located at 0x3000_xxxx

This makes absolutely no sense to me, and can anyone explain what I did wrong?

Thanks

Matthew

[Pavel A.]

> can anyone explain what I did wrong?

Likely, your edits in the linker script  moved the pool or section from which threadx allocates stacks. Review the changes.

[matt-crc]

The .nx_data is defined in RAM_D2 and starts from address 0x3000_0100.  I then defined the .NetXPoolSection at different locations between compile / debug sessions.  And it appears that ThreadX always puts the thread stack right in the middle of the NetXPoolSection.

@Pavel A.  - Hi, I don't see any issue with the flash.id file.  I have attached complete file, and let me know if you see something.. thanks

Matt

[matt-crc]

Hi @Pavel A. 

I don't think it is a problem with the linker script...

There are 3 tasks that are created.  

1- Netx ip instance

2- Net Duo App thread

3- Blinky

All are created in one file.  The first 2 netx threads have the ThreadX stack in the middle of the NetxDatapool, and the Blinky task has the correct stack location.

The NetxDatapool has a size of 40K, and in this run / debug session,  NetXDatapool starts at 0x30010000.  Which means, I expect the datapool to end at 0x3001BFFF.

ThreadX put the stack for both threads 0x30013e68 and 0x30014A78

Attached is the .c file that created the tasks.

.

[matt-crc]

@Pavel A. 

More info... if I delete the RAM_D2 section completely, and put everything in RAM_D1, and assign the .netxdatapool to 0x2403000.  Again, ThreadX puts the Stack is right in the middle of the NetxDuo data pool.

Blinky task, which is defined right after is then back in the correct location at 0x2400xxxx

I just don't get it.

Matt

[Pavel A.]

In your .c file, the blinky stack is in a simple static array which should go to default BSS section. Which is in RAM_D1, OK. Other thread stacks are allocated from the pool. Find why the pool landed to a wrong place.

[matt-crc]

It appears to be an ST bug - 

the code in question was all auto-generated by CubeMX

Can someone from ST look at this?

[matt-crc · Accepted solution]

Ok, I went through the NetxDuo code, and finally figured out what they were doing.  Everything associated with the NetxDuo, runs out of the .NetXPoolSection which includes the thread stack.  Anyway, now that I have a better understanding of the NetXPools, i was able to get it to work reliably.

Thanks for the responses and help.

Matthew