2021-12-16 02:39 PM
2021-12-16 02:54 PM
Suggest you pick one post, and edit it to have summary, question, and context
Edit is in a small [V] icon, upper right of pane.
2021-12-16 03:13 PM
Sorry. Thought I was searching for an answer. It has been a very frustrating long day. I did try to delete both posts but the delete options responds that I am not allowed to delete.
2021-12-16 03:21 PM
And did you find the answer? If not, perhaps you may want to elaborate on description of the problem?
JW
2021-12-16 03:40 PM
No I have not so here is the detail. Again I apologize for any confusion.
I am trying to use the Azure RTOS and the thread processes are working fine. I want to add queue handling so added a test queue.
After the thread creations and the event flags group I added:
/* Create the Queues */
//Allocate queue memory
if (tx_byte_allocate(byte_pool, (VOID **) &pointer, MCU_CMD_QUEUE_SIZE*sizeof(ULONG), TX_NO_WAIT) != TX_SUCCESS)
{
ret = TX_POOL_ERROR;
}
if (tx_queue_create(&Queue_CMD, "Queue MCU Command", TX_1_ULONG, pointer, MCU_CMD_QUEUE_SIZE*sizeof(ULONG)) != TX_SUCCESS)
{
ret = TX_QUEUE_ERROR;
}
Later in the code I try to send a message with:
ULONG message;
message =1;
status = tx_queue_send(&Queue_CMD, &message, TX_WAIT_FOREVER);
if (status != TX_SUCCESS)
{
Error_Handler();
}
The code ends up in the fault handler.
Can't figure out why.
2021-12-17 12:48 AM
Which STM32?
This will be Azure-specific so you should perhaps seek help at their support, if there's any. Don't think he are any Azure users. Also you can try to debug as hardfaults are devices usually - look at the fault registers, and also from the stacked PC and disasm look up the offending instruction and if it's a portion to which you have the sources, you may estimate the reason.
JW
2021-12-19 03:20 AM
Hi @Community member
Could you please give more details about your test.
regards
Haithem
2021-12-20 09:46 AM
STm32H723ZG Nucleo board
AZRTOS - 2.0.0
STM32CubeIDE - GNU(9-2020-q2-update)
I did find in the STM32H723ZGTX_FLASH.ld that the ._threadx_heap assignment was missing. I thought that odd since this was taken from the Tx_Thread_Creation example application for the nucleo board I am using. That example was working before I added the use of a queue and perhaps no assignment in the linker is needed when not using message queues. At the moment I amusing:
._threadx_heap
{
. = Align(8);
_RAM_segment_used_end__ = .;
. = . + 32K;
. = ALIGN(8);
} >RAM_D1
The section above is placed after .bss and before ._user_heap_stack.
However I am still ending up in the HardFault_Handler.
The HFSR->FORCED is set and the CFSR->BFARVALID and CFSR->PRECISERR are set.
2021-12-20 02:13 PM
Going further, I find after inserting the threadx_heap statement in the .ld file the error has moved to the next threadx statement which suspends the current thread that had invoked the tx_queue_send with the statement tx_event_flags_get().
I really think this is a STM32 tool issue since neither the starting example or the CubeMX is putting the threadx_heap statement in .ld file. It does not appear to affect the thread creation and ability to use events but when adding queues it fails to run. In all the other examples I have seen the threadx_heap statement is present. Perhaps the ability to modify the ld file is a feature that is not yet implemented but certainly looks like it is needed.
Still cannot figure why I am ending up in the Fault_Handler.