Not applicable
May 24, 2017
05:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 24, 2017
05:07 AM
Hallo Everybody,
I discovered a strange behavior in the DAVE_Init function. It seems that sometimes the sequence in which the individual APP instances get initialized plays a role if the startup succeeds or not.
I my specific case I had several APPs in place (ADCs, Timer, DACs, etc.) Finally, I added a FATFS APP instance to store data. This caused the DAVE_Init() function to crash (the XMC did not ever boot properly - no error message)
After changing the sequence of initialization within the Dave\Generated\DAVE.c (putting the FATFS APP first) everything worked just fine. Unfortunately, you must change the sequence every time you press the auto code bottom.
Is there any way to influence initialization sequence permanently?
Thanks in advance!
I discovered a strange behavior in the DAVE_Init function. It seems that sometimes the sequence in which the individual APP instances get initialized plays a role if the startup succeeds or not.
I my specific case I had several APPs in place (ADCs, Timer, DACs, etc.) Finally, I added a FATFS APP instance to store data. This caused the DAVE_Init() function to crash (the XMC did not ever boot properly - no error message)
After changing the sequence of initialization within the Dave\Generated\DAVE.c (putting the FATFS APP first) everything worked just fine. Unfortunately, you must change the sequence every time you press the auto code bottom.
Is there any way to influence initialization sequence permanently?
Thanks in advance!
- Tags:
- IFX
4 Replies
May 29, 2017
02:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 29, 2017
02:00 AM
Hi,
It is not possible to influence the initialization sequence generated by DAVE_Init().
You can alternatively call your own DAVE_Init() in main.c
I would be interested in looking to the root cause of your observation. Would it be possible for you to share the project?
Regards,
Jesus
It is not possible to influence the initialization sequence generated by DAVE_Init().
You can alternatively call your own DAVE_Init() in main.c
I would be interested in looking to the root cause of your observation. Would it be possible for you to share the project?
Regards,
Jesus
Not applicable
Jun 01, 2017
02:01 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 01, 2017
02:01 AM
Jun 02, 2017
05:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 02, 2017
05:56 AM
Hi,
The problem is the ADC conversions start triggering after initialization.
These triggers the FilterArrayReady_Handler execution before the Filter0_I is initialized, which triggers a bus fault since inside the mentioned function some members of the structure gets deferenced pointing to 0.
The solutions:
1. Move the initialization of all variables before the DAVE_Init() as attached.
2. Unclick the "Start during initialization" in the PWM_CCU8_0_ADC_TRIGGER. You can start later on using the API, PWM_CCU8_Start (PWM_CCU8_t *handle_ptr).
BTW: To debug this cases, in the CPU_CTRL_XMC4 activate the hard fault debugging option.
Regards,
Jesus
The problem is the ADC conversions start triggering after initialization.
These triggers the FilterArrayReady_Handler execution before the Filter0_I is initialized, which triggers a bus fault since inside the mentioned function some members of the structure gets deferenced pointing to 0.
The solutions:
1. Move the initialization of all variables before the DAVE_Init() as attached.
2. Unclick the "Start during initialization" in the PWM_CCU8_0_ADC_TRIGGER. You can start later on using the API, PWM_CCU8_Start (PWM_CCU8_t *handle_ptr).
BTW: To debug this cases, in the CPU_CTRL_XMC4 activate the hard fault debugging option.
Regards,
Jesus
Not applicable
Jun 07, 2017
08:33 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 07, 2017
08:33 AM
Awesome! Many thanks Jesus!
I could reproduce both solutions - both fix the problem.
Thanks as well for the hint with the hard fault debugging option - this widened my horizon 😉
Best
Christoph
I could reproduce both solutions - both fix the problem.
Thanks as well for the hint with the hard fault debugging option - this widened my horizon 😉
Best
Christoph