2018-11-30 12:50 AM
After the firmwared (or power off-on) and after the reset the same program takes a different amount of time in ticks. Find it in my oun code. Then tried to create code in Cube and check it - same thing. Then I checked clocking settings and frequency - it was same and after power off-on and after reset (HSE 8MHz, Sys 216M). Then I checked systic interruption systic (setting for 1ms), and it always was 1ms.
What to do and why it can be?
For example the simplest program:
volatile uint32_t *DWT_CONTROL = (uint32_t *)0xE0001000;
volatile uint32_t *DWT_CYCCNT = (uint32_t *)0xE0001004;
volatile uint32_t *DEMCR = (uint32_t *)0xE000EDFC;
volatile unsigned int *DWT_LAR = (volatile unsigned int *)0xE0001FB0;
uint32_t Mcounter, count;
main()
{
*DWT_LAR = 0xC5ACCE55; // unlock (CM7)
// enable the use DWT
*DEMCR = *DEMCR | 0x01000000;
// Reset cycle counter
*DWT_CYCCNT = 0;
// enable cycle counter
*DWT_CONTROL = *DWT_CONTROL | 1 ;
SystemClock_Config();
while(1)
{
u8 i=0;
Mcounter=*DWT_CYCCNT;
i =1;
count=*DWT_CYCCNT-Mcounter;
float op_time=count/216.0f;// count/F_CPU
SendToUart(count);
}
}
count after power off-on = 0;
count after reset = 34 ticks;
2018-11-30 01:46 AM
help...somebody..please
2018-11-30 03:30 AM
What tool chain? What optimization level?
Have you looked at the generated code?
2018-11-30 03:59 AM
Quick test on F746G-DISCO, cleaned code up, but seems not to clock after power cycle
Hello World!
5 12
3 200190208
3 400390211
3 600590210
3 800790208
3 1000990210
3 1201190208
3 1401390212
3 1601590211
3 1801790208
3 2001990208
0 0 << Stopped Debugging in Keil
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
Hello World! << Reset Button
3 11
3 200190212
3 400390212
3 600590215
3 800790212
3 1000990215
3 1201190212
3 1401390216
3 1601590215
3 1801790212
3 2001990215
3 2202190212
3 2402390214
3 2602590216
3 2802790215
3 3002990214
3 3203190215
3 3403390216
3 3603590212
3 3803790216
Hello World! << Pulling off power jumper and reinstalling
0 0
Hello World!
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
2018-11-30 03:59 AM
where are you?
2018-11-30 05:00 AM
RU, Siberia and unclear_how_the_code_works
2018-11-30 05:05 AM
IAR7.5->FlashLoaderDemonstrator->mcu. My code (and tried cube's code on LL and on HAL). No optimization. I tried this code on stm32f407, it takes less ticks (11). But it disassembling equally on 407 and on 745
2018-11-30 05:17 AM
Changing the ordering helped,
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 DWT_Check(void)
{
*SCB_DEMCR |= 0x01000000; // enable scb/debug first
*DWT_LAR = 0xC5ACCE55; // unlock
*DWT_CYCCNT = 0; // reset the counter
*DWT_CONTROL |= 1 ; // enable the counter
while(1)
{
volatile uint8_t i = 0;
uint32_t count;
uint32_t start = *DWT_CYCCNT;
i = 1;
count = *DWT_CYCCNT - start;
printf("%5d %10u\n", count, *DWT_CYCCNT);
HAL_Delay(1000);
}
}
2018-11-30 05:35 AM
o, thanks, it and helped and didn't,
Now it works like this:
download mcu -> count = 53
reset mcu -> count = 97
power off-on -> count = 97.
Problem with strange behavior after downloading remained.
It may be due to:
*FLASH->ACR? (latency 7, ART and prefetch disable, axim in icf)
*cache?
2018-11-30 07:33 AM
My test consistently reports 3 cycles in Keil.
The counter didn't work on a power cycle, unless I ran the register write code twice, or changed the ordering to put the SCB enable first.
Not sure what your problem is now.