-1

I am trying to test out the sample/demo code for ThreadX on an STM32L0 Cortex M0+ controller. Specifically the sample_thread.c code found on GitHub. I used the example code for the cortex M0 port and compiled the code. At this point all is good, or so I think, the port looks like it is mapped correctly for my controller; i.e. memory start address and RAM are correct.

The issue I am having is that I am getting a hardfault during some functions for dynamic memory allocation, when allocating space for threads. I find that the hardfault is triggered within the function _tx_byte_pool_search(), it happens when the block pointers are checked, in one instance here:

*next_block_link_ptr =  *this_block_link_ptr;

When this line is executed, one of the block pointers ends up with an invalid address outside of the memory area, usually with 0xAAAAAAAA. I'm trying to understand how exactly ThreadX is constructing these blocks of memory, but I shouldn't have to. This function should work as intended but it isn't. So I'm thinking that I am doing something wrong, but have run out of ideas to check. If someone with some more experience can provide some direction or ideas that would be helpful.

I have setup the startup code in _tx_initialize_low_level.S to provide the address of first_unused_memory, which is used for tx_application_define(). I thought that this address was basically what was required for the memory allocation stuff to work. Maybe I am missing something.

Thank you all for the help.

James
  • 1
  • 1

1 Answers1

0

The problem you describe hints at a mismatch on how memory is being assigned to different parts of the program. The two points I would check first, as you did, is the linker script file and that the location of the end of the allocated RAM is defined properly. The problem could be also somewhere else, but these are likely the reasons.

First of all make sure that the linker file matches your system. Consult the the processor reference manual and data sheet. You haven't mentioned which toolchain you are using, the linker command file (or linker script file) format will differ between toolchains.

Second, the location of the end of the used memory, and the beginning of the free memory should match your system. You can look at the linker output, typically stored in a map file, to understand how much of the memory is being used by the application. Make sure that this is what is being passed to the tx_application_define.

A better way to handle this second point would be not to use this parameter at all, but allocate memory statically (as global variables) for each element (thread control blocks, other control blocks, thread stacks, etc). The basic example uses this convoluted way of allocating memory for two reasons: to be flexible enough to run unmodified in many different architecture, and to show as much of the API as possible in a small amount of code; interesting as a demo, but not the preferred way to use the system.

Andrés
  • 51
  • 3