We are trying to use RA0E1 in a commercial project,ADC12 module is working without problems so far starting our application via hal_entry() (without ThreadX).
But using ADC12 in a ThreadX project always leads to a BSP_CFG_HANDLE_UNRECOVERABLE_ERROR in the Default_Handler().For verifying the cause I stripped everything back to a "bare metal" ThreadX project (New Renesas C/C++ project with Azure ThreadX => Minimal => Add New thread).
Without adding an initial R_ADC_D_Open the single/only thread runs fine with regular APP_PRINT output on an RTT Viewer terminal.
After adding/activating an initial R_ADC_D_Open(&g_adc0_ctrl, &g_adc0_cfg) (see code below)
#include "new_thread0.h"
#include "common_utils.h"
#include "r_adc_d.h"
extern adc_d_instance_ctrl_t g_adc0_ctrl;
extern const adc_cfg_t g_adc0_cfg;
/* New Thread entry function */
void new_thread0_entry(void)
{
fsp_err_t err = FSP_SUCCESS; // Error status
err = R_ADC_D_Open(&g_adc0_ctrl, &g_adc0_cfg);
/* handle error */
if (err != FSP_SUCCESS)
APP_ERR_PRINT("** R_ADC_D_Open API failed ** \r\n");
}
while (1)
APP_PRINT("\r\nMain thread running ...");
tx_thread_sleep (200);
R_ADC_D_Open always returns FSP_SUCCESS but immediately thereafter ThreadX runs into the exception shown below:/*******************************************************************************************************************//** * Default exception handler. **********************************************************************************************************************/BSP_SECTION_FLASH_GAP void Default_Handler (void){ /** A error has occurred. The user will need to investigate the cause. Common problems are stack corruption * or use of an invalid pointer. Use the Fault Status window in e2 studio or manually check the fault status * registers for more information. */ BSP_CFG_HANDLE_UNRECOVERABLE_ERROR(0);}Playing around with several stack constellations (raising Thread Stack size, Timer Thread Stack, Main stack and Heap size) did not help.
The same problem occures also, when further code for ADC sampling is added, then always ONE correct ADC measurement is done but immediately thereafter program/thread execution runs into the same exception.
Can anybody help ?
Hi HarLey,
Thanks for reahcing out Renesas Community.
The problem is caused by the ADC interrupt, there are two ways to solve the problem:
First, disable the ADC interrupt but this is not a suggested way.
Second, when using ADC module in ThreadX, please add the ADC in new thread and change the Maximum Interrupt Priority of this thread to priority3:
By default, this setting is priority0 which means disable the interrupt in this thread:
So you have to change it manually to enable interrupt.
BR,
NP_Renesas
As mentioned 8 days ago, help would be very appreciated, because ThreadX always gets stalled after ADC12 is opened, independent of the way how it is done/used.Is there any progress with this matter ?We really need urgent help, because we are trying to use ADC12 together with ThreadX in a commercial project with hard deadlines ...
If you are not using the scan end interrupt you should set the interrupt property to disabled in the common properties for the ADC.
If you are using the interrupt then you need to specify a callback function and you can set a semaphore in the callback to notify the thread that the ADC sample is ready and can be read. That way you can set a timer to trigger the ADC automatically and have the thread pend on the semaphore, read the ADC value and process it at thread level.
I have tested and verified that this works with ThreadX.
-Gary
Hi Garyj, many thanks for your proposals,may I ask on which µC of the RA family this works for you with ThreadX ?
I tested this on the FBP RA0E1.
Ok, thanks. And which FSP version are you using ?
Ok, thx again, that may help ...