I wanted to know if a JTAG debugger can access debug enabling registers of CORTEXM4 like DHCSR while the Power on reset and System reset has been asserted.
Or do we deassert only the Power On Reset and access the registers with System Reset asserted?
If I want the processor to get into debug mode out of reset, the debugger will have to set the DHCSR.C_DEBUGEN bit to 1. Can this register be accessed when the Power on Reset and System reset has been asserted?
Just needed information on the reset sequence for an external JTAG to program the CPU to get into debug mode right after all the resets have been deasserted.
Related
I working with EFM microcontroller (Silicon Labs)
I need to make a beep every x seconds, when the device in EM3 mode.
I tried so many ways without success.
Please try to help me with code example (I'm HW man, not a SW haha)
Thanks,
Gal.
Refer to page 8 on the datasheet (thanks to #user694733)
EM3 mode description:
still full CPU and RAM retention, as well as Power-on Reset, Pin reset and Brown-out Detection, with a consumption of only 0.6 μA. The low-power ACMP, asynchronous external interrupt, PCNT, and I2C can wake-up the device.
So these are your options. One of these things can wake up the microcontroller. All of them are external inputs. So the microcontroller cannot wake itself up in this mode. This makes sense because all clocks are stopped.
If you had an outside clock connected to the PCNT you could use that to wake it up.
If you want the microcontroller to wake itself up, then you need EM2 mode or less:
In EM2 the high frequency oscillator is turned off, but with the 32.768 kHz
oscillator running, selected low energy peripherals (LCD, RTC, LETIMER,
PCNT, LEUART, I2C, WDOG and ACMP) are still available
In EM2 mode the microcontroller may wake itself up using the RTC (real-time clock), LETIMER (low-energy timer), WDOG (watchdog timer) or PCNT (pulse counter, which can be set to count pulses of the 32.768kHz clock).
The datasheet recommends using the Real-Time Clock or Low Energy Timer (RTC or LETIMER) modules.
... however, if we pay attention, we see the datasheet mentions something called the ULFRCO, Ultra-Low-Frequency RC Oscillator, which runs at approximately 1000 Hz. By searching for the keyword ULFRCO, we see that it does still run in EM3 mode, and it can be used as input for the WDOG. On page 89 we see this listed as a feature of EM3 mode.
So, you may configure the WDOG to reset the system after a few seconds. When the microcontroller resets due to watchdog timeout, it wakes up. You should not be afraid of using a system reset. The RMU_RSTCAUSE allows you to see that the system was reset because of the watchdog timer (not because it was first turned on or the reset pin was used). Memory contents are probably still there, but all peripherals are reset. As long as you can deal with peripherals being reset, you can probably make this work. You might even be able to use a little bit of assembly programming to jump back to exactly the point where the program left off.
I am currently playing with L152C Discovery board and trying to make simple clock that would use the RTC build into the STM32 and onboard Glass LCD with LCD HAL library configured via CubeMX.
But I am currently facing a problem I can't get my head around:
CubeMX does not have an option to enable segment mux in the LCD_CR register. I would like to enable it, because it would make the segment mapping easier.
So I thought, fine, I will make an direct register manipulation, enabling the mux (bit 7 in the LCD_CR).
I used the command LCD->CR |= LCD_CR_MUX_SEG; But even after executing the command, the MUX_SEG bit is still zero. (I checked in the debug session with command stepping and SFRs memory map)
Is there something that I am doing wrong? Or is there another way to change init parameters that CubeMX configured but does not have graphical implementation of this settings option?
The application is using FreeRTOS and I executed LCD->CR |= LCD_CR_MUX_SEG; after HAL_LCD_Init(&hlcd); so I sappose that the LCD peripheral clock is running (and segments are updating).
I recorded a short video showing this problem:
https://youtu.be/0X6Zu5EPudU
To be honest, I am not skilled at direct register manipulation, so I am probably doing something wrong.
Any help would be appreciated!😇
As #KIIV said:
RM0038 Liquid crystal display controller (LCD) Note: The VSEL, MUX_SEG, BIAS and DUTY bits are write protected when the LCD is enabled (ENS bit in LCD_SR to 1).
The LCD must be disabled when making changes to the above registers.
I have a ChibiOS 3.x program on a STM32F4 microcontroller where I use the IWDG watchdog to reset the MCU on errors like this:
int main() {
iwdgInit();
iwdgStart(&IWDGD, &wd_cfg);
while(true) {
// ... do stuff
}
}
If I now attach my debugger and, at any point, stop the program (manually or via a breakpoint), the microcontroller will reset after the timeout defined by the watchdog configuration (and therefore cause issues in my debugging process)
How can I disable this behaviour, i.e. how can I disable the IWDG while the core is stopped due to the debugger?
I have tried disabling it entirely, however, I need to leave it running to catch unwanted IWDG resets.
The STM32 MCUs contain a feature called debug freeze. You can stop several peripherals, including I2C timeouts, the RTC and, of course, the watchdog.
In the STM32 reference manual, refer to section 38.16.4ff "MCU debug component (DBGMCU)".
The IWDG is running on the APB1 bus. Therefore you need to modify DBGMCU_APB1_FZ, most specifically assert the bit DBG_IWDG_STOP in that register.
The POR value (= default value) for this register is 0x0, i.e. if you not actively disable it, the IWDG will still be running.
int main() {
// Disable IWDG if core is halted
DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_IWDG_STOP;
// Now we can enable the IWDG
iwdgInit();
iwdgStart(&IWDGD, &wd_cfg);
// [...]
}
Note that when not enabling the watchdog in software, it might still be enabled in hardware if the WDG_SW bit is reset in the flash option bytes.
If you are using the ST HAL (not included in ChibiOS, see STM32CubeF4), you can also use this macro:
__HAL_DBGMCU_FREEZE_IWDG();
(which basically does exactly the same as we did above)
Besides, you need enable the DBGMCU clock on APB2 before calling __HAL_DBGMCU_FREEZE_IWDG().
__HAL_RCC_DBGMCU_CLK_ENABLE();
When using the ST HAL, the right macro to use is:
__HAL_DBGMCU_FREEZE_IWDG()
According to the reference manual, the DBGMCU_CR register "can be written by the debugger under system reset", so, if the debugger supports it, there is no need for changes in the software.
For instance, in STM32CubeIDE (as of now Version 1.6.0) just set Project > Properties > Run/Debug Settings > Launch configurations for [project name]: > [project name] Debug > Edit > Debugger > Device Settings > Suspend watchdog counters while halted:
to Enable.
I'm writing a kernel (using qemu to simulate) for x86 as a school project and I ran into weird problem.
Even though I have set the interrupt flag in the eflags register, I'm sill not getting any clock interrupts (I checked with qemu info register command and I see eflag=0x292 which means it is set).
To be precise when I run a spin test (while(1); program) in user mode, I get one clock interrupt, but after that one, it stops, qemu does not seems to simulate more! did it happen to anyone else? Is there another mechanism that can affect interrupts?
Anyone have a clue?
Shai.
Apparently in x86, you have to acknowledge clock interrupts after each one.
I.e one must sent an acknowledgment to the lapic after every clock interrupt.
If you are expecting interrupts from the RTC, you must acknowledge the previous interrupt first by reading from REG_C (CMOS register 0x0C).
I am using EWARM IDE from IAR with an Olimex development board for the ARM STR712FR2, and a J-link JTAG debugger provided by IAR. For some reason, I can't seem to write to the UART TxBUFR register. I believe I have configured all the clocks and baud rate correctly. The datasheet says that when I write to the TxBUFR register, the UART is supposed to immediately start transmitting. I am running this in debug mode, and when I place a breakpoint right after I set the TxBUFR to a value, the register still shows 0x0000, unchanged.
The register value may not change or it may be write-only, have you checked to see if it is actually transmitting or not?
The UART_CR register resets to 0 which has some fields set to reserved values. Have you configured all the fields in here? ALso, as was mentioned, UART_TxBUFR is a write-only register, so you will not be able to read the value back.