I have been using ST F4-Discovery board for some time, as many of other friends. We all have the same problem. We are using Keil IDE (used different versions from 4.3 up to 4.7). Whenever we time anything using breakpoints and stopwatch, it works perfectly when in simulation mode. However, when we are debugging on-board and run the same code, the stopwatch never reports correct timing. It is actually random. Does anyone know what the problem is?
Thanks
Stopwatch is based on the internal register SEC. There seems to be a bug that if the register window is not showing then the stopwatch values are not updated. When debug is running select View|Register window and make sure you can see the SEC register value updating. The stopwatch in the status bar should now be updating too.
To solve the problem of the stopwatch, go to: Tarjet options - debug - setting - trace - core clock and adjust the frequency to 72MHz or core of your processor.
I found the answer much later in time. It has to do with the internal debug circuitry. By default, the timer peripherals do not stop when we hit a breakpoint in debug mode but continue counting. This is why we keep getting random measurment intervals between timer interrupt instances using the stop watch. In order to get accurate timing, we need the debug circuity to force the timer peripheral to stop counting once we reach a breakpoint and resume later once we step over it. This can be done by writing this code:
SET_BIT(DBGMCU->APB1FZ, DBGMCU_APB1_FZ_DBG_TIM3_STOP);
Which instructs timer 3 on APB1 bus to stop counting at breakpoints.
Related
Using Nucleo STM32H723 board making an alive LED toggle in the StartDefaultTask.
osDelay(10000) gives exactly30 seconds of delay. I'm using timer7 as systick timer.
Bonus info:
FreeRTOSConfig.h
#define configCPU_CLOCK_HZ ( SystemCoreClock )
"SystemCoreClock" is initially set to 64MHz (HSI) but during start-up initialized to 216MHz (SYSClk). If I edit "FreeRTOSConfig.h" and set "configCPU_CLOCK_HZ" to 64000000 osDelay is now correct, but I would like to be able to generate the clock and rtos config with CubeIDE.
Maybe someone can tell me what I am doing wrong...
I am not familiar with that board, but I think the OS thinks SysTick ticks # 1/3 speed of its actual (hardware) speed. You have to sync that value to the OS. Check your FreeRTOSConfig.h file for configSYSTICK_CLOCK_HZ and related parameters. As for the CubeIDE/FreeRTOS integration, check the suitable extensions/expansions of the IDE. Other than that, you have to edit files manually...
I am using STM32 cubeMX for configuration and Keil for programming.
Have set onboard led pin pc13 pin as an output pin and default in push-pull mode. Set debugger to the serial wire as I am using ST-link V2 as a debugger. RCC set HSE to crystal/ceramic resonator.
and clock configuration set to default and generated project.
Now I started with a simple LED blink program. As below
HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
HAL_Delay(1000);
build successfully with no error and uploaded and wonder my led was not blinking and shocked as I have done this before and now this is not working.
when I debugged step by step and my code was just going from two functions repeatedly.
while ((HAL_GetTick() - tickstart) < wait)
{
}
__weak uint32_t HAL_GetTick(void)
{
return uwTick;
}
Nothing happens more in this code I know the code is right but there is some error in the HAL_delay configuration.
After scratching my head for a day I tried uploading the following code
HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
HAL_Delay(100);
And strange thing is that now my led is blinking only I have change the HAL_dealy value from 1000 to 100 and it works fine but, when using 1000 does not work at all.
So for testing, I gradually increased the delay value and I find that more than HAL_delay(400) it does not work.
Not able to find cause for this Any help will be appreciable.
As suggested by Tom I debugged uwTickFreq using STstudio.
and I got the following output waveform.
After that, I also uploaded the following code. And defined a variable as "unsigned long int a;"
HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
HAL_Delay(100);
a= HAL_GetTick();
Now I debugged the value of a using STstudio. And strange the value of a becomes 0 once it reached around 300.
It seems like finally, I got the problem when I noticed the reset problem in the controller I searched around and find something here.
So I checked my optional bytes set in MCU with the STM32 cube programmer.
It was set as below.
Therefore I enabled these three optional bytes.
And the problem of reset was gone and I am now able to use the HAL_delay function properly and now the value of HAL_GetTick() is also increasing more than 300.
Still have one dought I think watchdog was causing reset but why it only cause that when I use the timing function.
I have an ATSAMD21E18A micro that I am using with semi-hosting. In order for the semi-hosting to work, GDB needs to be "attached" before the first bkpt instruction. On the other hand, I have inexplicably found that the SysTick interrupt will not fire if GDB was already attached when I configured it. If I want to the SysTick interrupt to fire, I have to perform a reset (power-off via a button) and tell GDB to continue when it hasn't yet configured the micro (that is, it hasn't sent breakpoints over or anything else), and then hit Ctrl-C to initialize debugging mode after the SysTick configuration but before we get to initialise_monitor_handles.
I have verified that the start function is only copying over the relocatable data segment, zeroing the zero segment, and setting the right initial stack pointer value. We are writing our code without libraries like CMSIS.
Also I can confirm that I have no issues when the debugger is not attached (JLinkGDBServer through an Atmel SAM-ICE), besides needing to remove the semi-hosting stuff.
Also, the SysTick COUNT does still correctly count even when the interrupts themselves don't fire. Also the SysTick pending interrupt bit PENDSTSET in ICSR, is in fact set when this happens.
My code follows:
int main()
{
// enable system timer interrupt
SYS_TICK->STATUS = 0; // (CSR)
SYS_TICK->PERIOD = 48000; // (RVR) fire at 1khz for 48mhz clock
SYS_TICK->STATUS = 0b111; // use processor clock, w/ interrupt, and enabled
SYS_TICK->COUNT = 1; // (CVR) avoid high unknown value
// dumb busy loop
util_idle_ms(2000); // <<< I hit Ctrl-C to break here!
initialise_monitor_handles();
// ... more system initialization and everything else
}
I have seen some similar seeming questions here on StackOverflow, but they seemed to be too vague to get good answers.
Edit:
Here are possibly relevant register values taken during the busy loop for the run that doesn't call the SysTick handler (no hard reset, GDB attached before SysTick configured):
SYS_TICK_CSR/STATUS: 0x10007
SYS_TICK_RVR/PERIOD: 48000
SYS_TICK_CVR/COUNT: 5245 (varies of course)
NVC_ISER: 0 (and we expect this since SysTick is considered an exception, and not an interrupt)
DHCSR: 0x30003/0x1030003 (C_MASKINTS is not set; I've seen both values show up)
ICSR: 0x400f00f (it really wants to run the SysTick handler)
PRIMASK: 0
xPSR: 0x2100000f (IPSR is 0x0f/SysTick)
And for the run that calls the SysTick handler just fine (hard reset with GDB attaching after SysTick configuration):
SYS_TICK_CSR/STATUS: 0x10007
SYS_TICK_RVR/PERIOD: 48000
SYS_TICK_CVR/COUNT: 16892 (varies of course)
NVC_ISER: 0
DHCSR: 0x10003/0x1030003 (I've seen both values show up)
ICSR: 0 (SysTick handler already run)
PRIMASK: 0
xPSR: 0x2100000f
So the register values here do not yet seem to reveal anything new to me... Please help inform me of other potentially relevant registers to check!
Just for interest, the reason this is important to me is because I have gotten gprof to work on this chip, based on https://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/
And although I do have to hit Ctrl-C at just the right time after a hard reset, it does work like this!
Edit
I have found that I had a misunderstanding where I thought running load in GDB performed a soft reset. I have since found that although it returns execution to reset vector, various peripherals and other registers are not in fact reset. If I perform a soft reset in GDB with monitor reset then I don't need to Ctrl-C during a delay to attach GDB and both SysTick and SemiHosting will work.
The problem occurs when SysTick is configured and then load is run in GDB, without an explicit hard or soft reset. In this case, SysTick does not fire interrupts. Most of my debugging went like this, loading new code and immediately expecting it to work so I could evaluate it. Just running monitor reset is a better workaround than before, but I still would prefer to know the reason for SysTick's misbehavior!
I would visit the ARM® v6-M Architecture Reference Manual and see if you can get some direction from that. https://static.docs.arm.com/ddi0419/d/DDI0419D_armv6m_arm.pdf
Observe that state of the registers related to the Systick that you didn't include in your question. If you can't figure out the problem based on those registers, edit your question and post the register values here (the NVIC ISER, all registers related to systick config, the DHCSR, and any others you think are related). They will be the key to getting more feedback.
The Debug Halting Control and Status Register (DHCSR) has the ability to mask interrupts including the systick. Maybe this is being set by the debugger?
bit 3 of the DHCSR looks relevant
I would also check that the SYST_RVR (Systick reload value register) is being set to something sane.
I don't have the rep to comment on your question, but I'm hoping this can get you going in a productive direction :)
So I was programming on my board with a ATSAM4S8Bu using an Atmel-ICE debugger happily when suddenly I was assaulted by this error message any time I tried to debug or deploy to my board:
Failed to launch program
Error: unexpected chip identifier 0x00000000
This error also sometimes gets shouted at me:
Could not activate interface, but found DAP with ID 0x2ba01477.
How rude of it! I tried reasoning with it but it is not having any of it.
but seriously, it was fine one moment and the next this error has stopped me from further development so what does it mean and how do I fix this?
EDIT:
This error only seems to occur on my machine. It works on my colleagues, I tried reinstalling atmel-usb and atmel studio 6.2 but no luck :(
EDIT:
Some screen shots of the screen im shown in Tools->Device Programming and then trying to read the devices signature:
EDIT:
I also seem to get this error sometimes instead:
I've had this problem too and I have found a couple of solutions that I would like to share.
My PCB was using an ATSAM4E processor (that had never been programmed) with a Cortex debug header. I got the error message when I tried either method (SWD or JTAG).
Note: I was able to read the Device ID for a very short window after powering the PCB on or after pressing the reset button (Credit to Yaro and Yarooo). Often I would have to try multiple times to try and hit that short window. This confirmed to me that my circuit of the Cortex Debug header was correct.
jrb114 quotes in his post that there is an errata on the SAM3S datasheet that requires:
an external crystal or ceramic resonator on XIN/XOUT, or use the Main oscillator in bypass mode (applying a clock on XIN).
...
So what I did to make these boards work was provide a 1 MHz clock to XIN using a signal generator. Apply power to the PCB, then connect using the ATMEL-Ice. This connects fine. After that I set the GPNVM Bit 1 so we boot from flash, not SAMBA, programmed the device and it works fine.
My PCBs had an external crystal so I was a bit confused why my boards didn't work. So I put an oscilloscope on the XIN line and found that the crystal was not generating a waveform.
It turns out that on most of my boards, there was a short between one of the capacitors (for the crystal) to ground. No wonder my clock wasn't going.
On the other boards, the inductor that goes between VDD_OUT and VDD_PLL was not soldered correctly to the PCB, causing it to be open circuit.
Overall, it appears that this error is a result of not having a clock signal on XIN, whether it be incorrect wiring or not using an external crystal/resonator.
I am experiencing a problem with FreeRTOS where it seems the systick() rate is 1/2 the expected rate. All timer or task delay functions take about 2X the time. This was verified in versions 8.2.0 and 8.2.3 using a STM32F100 processor.
There is another posting that looks very similar. This developer is using a MSP430 and claims the tick rate is 400Hz when expecting 1000Hz tick rate.
The RCC register configuration appears to be correct. If I create a non-FreeRTOS project where the systick is correct, it has the same RCC configuration as in the FreeRTOS version.
Suggestions?
When I read:
I created a very simple task that delays for 4 seconds and reports the
actual number of elapsed ticks. The ticks are correct but the actually
delay is around 8 seconds.
When reading this my thought was, if the delay is correct in the number of ticks, but the time is different, then this is simply a case of the CPU clock running at a different frequency to that which you think it is. Perhaps configCPU_CLOCK_HZ is wrong. However, then you write:
#undef OS_USE_TRACE_SEMIHOSTING
#define OS_USE_TRACE_ITM
you mention semihosting. Are you using semihosting? If so, don't, it will mess up your timing as it will stop the CPU while outputing to the host - and that might be the problem you are seeing.