Open AndronikosKostas opened 1 week ago
Tested on the old comms-eqm-software.
In the FreeRTOSConfig.h file we have the following defines
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5
So any interrupt service routine (ISR) that has a priority greater than 5
(like 0
, 1
, 2
, 3
, or 4
) should avoid calling FreeRTOS functions directly. Doing so could lead to unpredictable behaviour, as higher-priority ISRs could disrupt the operation of the FreeRTOS kernel.
For example if you set an interrupt in CubeMX having a value of 1 is wrong and could disrupt the operation of FreeRTOS kernel.
Another observation was that in the old comms-eqm-software that was tested on CSF the PendSV IT was set to 15 which is the lowest priority and it is not recommended.
Note: The Pendable Request for System Service (PendSV) is a crucial part of the ARM Cortex-M architecture that enables efficient context switching in real-time operating systems like FreeRTOS.
Update: The issue was not the FreeRTOS but the CubeMX configuration (Enable TX and RX swapping)
When I am using the following
HAL_UARTEx_ReceiveToIdle_DMA(&huart5, gnssTask->incomingMessage, 5000);
So the callback is called when the buffer is full and half-full...so the IDLE might not work properly
Also after each receive you have to run again the following
__HAL_DMA_DISABLE_IT(&hdma_uart5_rx, DMA_IT_HT);
This will cause the IT to be called each when the buffer is full
The IDLE only triggers when UART global interrupt is enabled... If you are using DMA on circular mode you are getting something like: while in normal mode: which seems constant at 460 bytes
CHECK this : e3896a813787f02cdf4b05b77fc9ce72c9dbf8f4
Files
GNSS.hpp, GNSS.cpp GNSSDefinitions.hpp GNSSMessage.hpp
Most Recent Branch
comms-eqm-software repo at the branch gnss_eqm
Reports
https://github.com/PeakSat/comms-eqm-software/issues/10 https://github.com/PeakSat/comms-eqm-software/issues/11 https://github.com/PeakSat/comms-eqm-software/issues/13
Chore Tasks
Data Handling
HAL_UARTEx_ReceiveToIdle_DMA(&huart5, this->incomingMessage, 512);
Functions that are tested and working
configureNMEATalkerID(TalkerIDType type, Attributes attributes
querySoftwareVersion(GNSSDefinitions::SoftwareType::SystemCode)
gnssReceiver.setFactoryDefaults()
Functions that we should check at GNSS.cpp
configureInterferenceDetection(InterferenceDetectControl control, Attributes attributes)
along withqueryInterferenceDetectionStatus()
. This could be useful to assess the validity of the GNSS data.configureMessageType(ConfigurationType type, Attributes attributes)
. We want NMEA format (I think it is the default but we should double check it).configureGNSSNavigationMode(NavigationMode mode, Attributes attributes)
. Maybe we will needAirborne
.configureSystemPositionRate(uint8_t rate, Attributes attributes)
. This could be useful for the velocity calculation issue.query1PPSTiming()
Again may be useful for the validity of the GNSS data.Notes
For all of the above functions that need to be checked, you can check this function as a reference
GNSSMessage GNSSReceiver::configureNMEATalkerID(TalkerIDType type, Attributes attributes) {
Payload payload;
payload.push_back(GNSSDefinitions::GNSSMessagesID::ConfigureNMEATalkerID);
payload.push_back(static_cast<uint8_t>(type));
payload.push_back(static_cast<uint8_t>(attributes));
return GNSSMessage{GNSSMessagesID::ConfigureNMEATalkerID, static_cast<uint16_t>(payload.size()), payload};
}
A simple workaround to check if you read ACK or NACK is the following
for(uint16_t i = 0 ; i< dmaRxSize; i++){
if(rxDmaBuffer[i] == 132)
LOG_DEBUG << "NACK";
if(rxDmaBuffer[i] == 131)
LOG_DEBUG << "ACK";
}
Tasks for the above functions
Error Reporting and Error Handling
queryInterferenceDetectionStatus()
returns true or something like thatOther