Help, what is going on ???
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-07 11:16 AM
Hi if anyone can help it will be very much appreciated
Yet another strange issue
so I have my stlink v2 debugger set up with Rowley crossstudio
everything works fine when debugging and running my code from the ide on my nucleo st32f446RE board, yet when I exit the ide and power down and re power, my target board does not run correctly as it did when debugging.
I have track the code down to where it is hanging and it is here
#pragma GCC push_options
#pragma GCC optimize ("O3")
void delayUS_DWT(uint32_t us) {
volatile uint32_t cycles = ( SystemCoreClock / 1000000L)*us;
volatile uint32_t start = DWT->CYCCNT;
do {
} while( DWT->CYCCNT - start < cycles);
}
#pragma GCC pop_options
it get stuck in this do while loop i believe ???
I use this code to generate a short us timer
can anyone please tell me why everything works fine when debugging in the rowley ide
yet when I power down and re power it hangs in this code ???
If I REM the above routine out, my board works fine, but without my short timer
thanks in advance for any help
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-07 11:40 AM
The debugger enables the hardware, you apparently do not
volatile unsigned int *DWT_CYCCNT = (volatile unsigned int *)0xE0001004; //address of the register
volatile unsigned int *DWT_CONTROL = (volatile unsigned int *)0xE0001000; //address of the register
volatile unsigned int *DWT_LAR = (volatile unsigned int *)0xE0001FB0; //address of the register
volatile unsigned int *SCB_DEMCR = (volatile unsigned int *)0xE000EDFC; //address of the register
void CycleCounter_Configuration(void)
{
*SCB_DEMCR |= 0x01000000;
*DWT_LAR = 0xC5ACCE55; // unlock CM7
*DWT_CYCCNT = 0; // reset the counter
*DWT_CONTROL |= 1 ; // enable the counter
}
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-07 11:46 AM
More happy fluffy version
CoreDebug->DEMCR |= 0x01000000; // TRCENA
DWT->LAR = 0xC5ACCE55; // unlock
DWT->CYCCNT = 0; // reset the counter
DWT->CTRL |= 1 ; // enable the counter
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-07 12:04 PM
Hey thank you
I simply wanted a way to count in micro seconds without using a timer and interrupts I don't think interrupts for microseconds is a good approach as to much time is taken servicing very fast interrupts. so I found this code on the web
Is this ok to use for micro second timers ???
I am still not really sure what is going on but I have added a routine with this in it
CoreDebug->DEMCR |= 0x01000000; // TRCENA
DWT->LAR = 0xC5ACCE55; // unlock
DWT->CYCCNT = 0; // reset the counter
DWT->CTRL |= 1 ; // enable the counter
I had to remove
DWT->LAR = 0xC5ACCE55; // unlock
as the compiler was complaining but now I switch off out of the debugger and yes, the board works and does not hang in the code,
thank you !
I'm guessing as you said the debugger was enabling the hardware and I was not ???
this gets a little misleading and what is the DWT ???
is this some other timer??,
the code I found on the web for a microsecond timer did not say about enabling any hardware etc.
so the fact my debugger did enable really confused this issue
Thank again :face_savoring_food:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-07 12:33 PM
DWT Data Watchpoint & Trace
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337h/BIIFBHIF.html
It is part of the debug unit that STMicro places on ALL it's parts, it is optional in Cortex-Mx implementations, but it is present here and has very good resolution/granularity. On the F1 parts there were NO 32-bit timers, and at 72 MHz had a wrap time close to a minute.
You don't want to interrupt at 1 MHz, this cycle count is typically good to a few tens of nanoseconds resolution.
You could use a 32-bit TIM, clock that at 1MHz via the prescaler, maximal period (0xFFFFFFFF) and then delta the TIMx->CNT in same manner to count microseconds. No need for it to interrupt, and preferable it doesn't.
The Lock/Access Register is needed on CM7 implementations (ie F7 and H7)
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-07 1:05 PM
thank you for the feed back
regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-11 4:09 AM
I notice that DWT->LAR doesn't seem to exist in core_cm4.h, but does exist in core_cm7.h.
Would I be right in thinking that I don't need to enable it for stm32f4?
Are there significant penalties for enabling DWT? I guess current consumption is tiny compared with the whole core.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-11 5:50 AM
I tend to use the top version, the CM7 requires unlocking, sometimes the debugger does this, but in standalone mode you must do it.
It is a 32-bit counter clocking at core frequency, I don't think the impact will be very high in the scheme of things, and it will be of a design that doesn't have critical path issues (carry propagation, etc).
Executing in a tight loop will burn energy, so I would use only for short spin loops where timing is most critical, and for 1ms based ones use SysTick based counts, and WFI to suspend between ticks.
Up vote any posts that you find helpful, it shows what's working..
