Not applicable
Jul 19, 2013
05:46 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 19, 2013
05:46 AM
I had a working project which included 4 x NVIC002 and 1 x SYSTM001 Apps.
I changed the interrupt priorities of them to 63, 62,61,60 and 10 respectively.
After this I found the SYSTM001 no longer runs.
Here are the SysTick settings after DAVE_Init() is called on a working project....
Here are the SysTick settings after DAVE_Init() is called on the broken project, SysTick has not been initialised.
DAVE_Init() calls SYSTM001_Init() and I found that the SysTick_Config() function shown below returns a Status value of 1 instead of 0.
Strangely, the 'if(Status == 1U)' code does NOT detect the 1 and the code jumps over the 'DBG002_ERROR(APP_GID,SYSTM001_ERROR, 0, NULL)' statement, so no error is reported.
I have reset all priorities back to the default of 63, re-generated code, cleaned the project and rebuilt all but I cannot get SysTick initialised.
I would really appreciate any advice on this and possible fixes without having to re-create the block diagram again.
Thank you in advance
Best regards
Aaron
I changed the interrupt priorities of them to 63, 62,61,60 and 10 respectively.
After this I found the SYSTM001 no longer runs.
Here are the SysTick settings after DAVE_Init() is called on a working project....
Here are the SysTick settings after DAVE_Init() is called on the broken project, SysTick has not been initialised.
DAVE_Init() calls SYSTM001_Init() and I found that the SysTick_Config() function shown below returns a Status value of 1 instead of 0.
Strangely, the 'if(Status == 1U)' code does NOT detect the 1 and the code jumps over the 'DBG002_ERROR(APP_GID,SYSTM001_ERROR, 0, NULL)' statement, so no error is reported.
I have reset all priorities back to the default of 63, re-generated code, cleaned the project and rebuilt all but I cannot get SysTick initialised.
I would really appreciate any advice on this and possible fixes without having to re-create the block diagram again.
Thank you in advance
Best regards
Aaron
- Tags:
- IFX
6 Replies
Not applicable
Jul 19, 2013
06:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 19, 2013
06:50 AM
One more observation.
The DAVE code generator is no longer updating the debug folder '....Project\Debug\Dave\Generated'
But DAVE is updating '....Project\Dave\Generated'
I don't know if this is important.
The DAVE code generator is no longer updating the debug folder '....Project\Debug\Dave\Generated'
But DAVE is updating '....Project\Dave\Generated'
I don't know if this is important.
Not applicable
Jul 23, 2013
03:27 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 23, 2013
03:27 AM
Hi Aaron,
What are the other interrupts? How frequent do they occur? Do take a note that the USB data handling interrupt priority level is only 63 (NVIC_SCU001).
Best regards,
Zain
What are the other interrupts? How frequent do they occur? Do take a note that the USB data handling interrupt priority level is only 63 (NVIC_SCU001).
Best regards,
Zain
Not applicable
Jul 23, 2013
03:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 23, 2013
03:40 AM
Thanks Zain,
Project is working again now. The CLK001 App frequency had been corrupted from 120MHz to 96MHz. Once this happens you have to change its value twice to reset it (in my case back to 120MHz).
It's possible this got corrupted when I changed ADCGROUP001 sample rate from it's default of 67 nS even though I reverted it back to 67 nS.
Best regards
Aaron
Project is working again now. The CLK001 App frequency had been corrupted from 120MHz to 96MHz. Once this happens you have to change its value twice to reset it (in my case back to 120MHz).
It's possible this got corrupted when I changed ADCGROUP001 sample rate from it's default of 67 nS even though I reverted it back to 67 nS.
Best regards
Aaron
Not applicable
Jul 24, 2013
12:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 24, 2013
12:03 AM
Hi Aaron,
Could you pls provide some more details on how to make the CLK001 App frequency being corrupted?
Best regards,
Sophia
Could you pls provide some more details on how to make the CLK001 App frequency being corrupted?
Best regards,
Sophia
Not applicable
Jul 24, 2013
12:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 24, 2013
12:18 AM
Hi Sophia,
I don't know if I can reproduce the problem at the moment but I believe the corruption of the clock frequency occurred when I changed 2 x ADCGROUP001 sample rates from defaults of 67 nS even though I reverted it back to 67 nS.
Georg had the project analysed by Infineon applications engineers who found the incorrect clock setting. The biggest problem for me was that no compiler errors / warnings occured and DAVE_Init() did not return an error.
Thank you
Best regards
Aaron
I don't know if I can reproduce the problem at the moment but I believe the corruption of the clock frequency occurred when I changed 2 x ADCGROUP001 sample rates from defaults of 67 nS even though I reverted it back to 67 nS.
Georg had the project analysed by Infineon applications engineers who found the incorrect clock setting. The biggest problem for me was that no compiler errors / warnings occured and DAVE_Init() did not return an error.
Thank you
Best regards
Aaron
Jul 30, 2013
11:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 30, 2013
11:02 AM
We found the root cause of this problem:
In some cases CLK001 App could propagate wrong clock information to other DAVE Apps that depend on the CLK001 App (e.g. SYSTM001, UART001, SPI001, CAN001, PWMx,). In such a case, clock related UIs such as baud rate configurations may show errors (red highlighted fields) or wrong initializations might happen.
Workaround to correct the problem if it occurs: Change the “Desired System Frequency” in the UI of the CLK001 App and change it back again.
To identify wrong initializations the DBG002 App may be used to log error codes and to use xSPY to transfer the error code in a log file to the PC.
A firm release date for a corrected CLK001 App cannot be given yet.
In some cases CLK001 App could propagate wrong clock information to other DAVE Apps that depend on the CLK001 App (e.g. SYSTM001, UART001, SPI001, CAN001, PWMx,). In such a case, clock related UIs such as baud rate configurations may show errors (red highlighted fields) or wrong initializations might happen.
Workaround to correct the problem if it occurs: Change the “Desired System Frequency” in the UI of the CLK001 App and change it back again.
To identify wrong initializations the DBG002 App may be used to log error codes and to use xSPY to transfer the error code in a log file to the PC.
A firm release date for a corrected CLK001 App cannot be given yet.