using Keil µVision on a STM32F4 I am trying to add a watchpoint to a GPIO data register, which just does not trigger.
I want the watchpoint to be triggered as soon as output data gets writting into this register.
Setting the watchpoint to the os timer work fine.
Peripheral registers are memory mapped in STM32 F4, as far as I know.
Any (simple) explanation that I am missing here?
Any hint is very much appreciated.
While the ARM core can access the peripheral I/O registers in the same flat 32-bit address space as SRAM or flash, peripheral I/O registers are located in separate buses on the MCU, and not accessed by the same bus as the SRAM. For example, on the STM32F, there are the ABH bus which are usually further divided into the APB1 and APB2 buses, depending on the device. In any case, the debug controller unit defined by ARM ("CoreSight"), provides data watchpoint capability, and it only works on "real" data access.
Would be great if it did though ;-)
No source, or personal experience, but I can think of a few reasons why this wouldn't work.
Often value isn't "there" like in RAM, but is created when you access a peripheral register.
You could say periodic access could then solve this, but that wouldn't work for registers where reading has side effects (usually clearing some status flag).
I think you'll have to create an interrupt handler for GPIO, and a breakpoint for that.
there is a workaround if 12 cycles latency is a problem. Use Pin as a trigger which triggers memory to memory DMA transfer. Set the watchpoint on the destination (or source) RAM address.
Related
Writing a simple UART program using CubeIDE 1.7.0 for a Nucleo-H723ZG board using DMA. A UART DMA receive call is issued waiting for input from a serial port app on the Mac OSX host (CoolTerm). A callback echoes the data received.
When a text message is sent to the board nothing but zeros is echoed back.
I noted that CubeMX had generated the DMΑ initialisation call (MX_DMA_Init()) AFTER the UART initialisation call (MX_USARTx_UART_Init()).
By Reversing the sequence of these two calls the code worked perfectly!
Is this my error, has something been missed in the setup, or is it an MX error?
This issue only affects CubeIDE 1.7.0 users on MacOSX Big Sur. Under Windows there is no problem and the code generator correctly positions the DMA initialisation call before that of the USART.
When using the MX configurator the peripheral initialisation calls are generated in the sequence in which they are entered. When setting up a USART to use DMA to perform the data transfer, two peripherals' initialisations need to be generated: the USART and the DMA device. As the USART was the first of the two peripherals selected the USART init call is generated before the DMA init call.
However, unknown to me at the time, the USART needs to set up a DMA register which must have its clock enabled. The DMA init must therefore be done BEFORE the USART init. Hence my problem.
Knowing this, in the MX Project Manager tab, the Advanced Settings tab provides the option to rearrange the sequence of these init calls and all is well!
So this is a bug. However, using a Nucleo-H743ZI2 with USART DMA there is no problem with out-of-sequence initialisation. Thus far the bug is limited to the Nucleo-H723ZG!
The firmware generated by CubeMX6.3.0 for Nucleo-G474RE does the same initialization inversion (UART before DMA) and leads to unresponsive code.
From what I understand, interrupt-driven I / O and DMA are two separate mechanisms, but I need to answer this question. I think the answer is no for the fact that it is not necessary
If a device uses DMA (Direct Memory Access), it is able to read or/and write directly from/to the main memory.
If a device can generate interrupts, it is able to notify the CPU that it requires attention.
So, DMA and interrupts are principally completely independent.
They can of course be combined, e.g. a device can notify the CPU that it has finished a DMA.
So, you are right, the answer is NO.
Hypothetical here: Let's say you have a processor attached to some form of USB-storage and a motor. How would I write a simple bare-metal program to tell the motor to move for 10 seconds? I want to learn how to bare metal program, and having a program to look at and analyze would be wonderful. (Any language would be great)
1) you have to understand how the processor in question boots. there is the core processor itself then the non-volatile storage. for example a raspberry pi is a little unique in that there is something in logic (or an on chip rom?) that reads the sd card, boots up the gpu, then the gpu copies the arm program to ram and releases the arm into that ram. most microcontrollers have on board flash and ram and the flash is mapped into the address space that the processor boots from and/or there is a vendor supplied bootloader that boots the processor then calls your code.
2) you have to learn how to enable and initialize the peripherals you care to use. a timer perhaps if you want to count to 10 seconds.
3) write the application.
debugging is the trick, you can sometimes use a hardware debugger via jtag or sometimes use a rom monitor via gdb or some other program on some interface like uart. or one that almost always is available either a blinking led or a uart to send text or numbers out to see what is going on. and of course an oscilloscope, you can wiggle gpios or do other things and see them on the scope.
driving a motor is too generic you need to specifically know what kind of motor and how to drive it, likely zero chance you are driving it directly from the microcontroller, you might have something outside a transistor h bridge or something that isolates the microcontroller or you have a specific type of motor driver chip/circuit that you speak to either through discrete signals, or i2c or spi, or other to tell it to drive the motor, and then maybe some analog to deal with the high power or maybe that chip is a hybrid. so you have to know all that or at least you have to know the programming side of all that, what interface and/or what signals have to have state changes in what way to cause the motor to do something. it could be as simple as a pwm that you create that is amplified between you and the motor. pwm may involve first learning how to mess with one of the timers then either another peripheral or a subset of the timer to make a pwm signal out of it. a scope is really helpful here too or a logic analyzer, or if you have another microcontroller you can sample a gpio in faster than the signal being generated you can turn it into a logic analyzer.
start with finding a board, blink an led, figure out how to run a timer, accurately blink an led. figure out the clock rates you are really running at instead of guessing, figure out how to configure the uart, send some characters out that, now you have a debug interface a knowledge of what your timer reference clock speeds are and can now try to count to 10 seconds, and then get into the signals needed for the motor. expect to blow up a few boards, buy some spares.
I want to write code for interrupts of the buttons on Raspberry pi 2. This board uses QUAD Core Broadcom BCM2836 CPU (ARM architecture). That mean, only one CPU is on this board (Raspberry pi 2). But I don't know how do interrupts in multi-core system. I wonder whether interrupt line is connected to each core or one CPU. So, I found the paragraph below via Google:
Interrupts on multi-core systems
On a multi-core system, each interrupt is directed to one (and only one) CPU, although it doesn't matter which. How this happens is under control of the programmable interrupt controller chip(s) on the board. When you initialize the PICs in your system's startup, you can program them to deliver the interrupts to whichever CPU you want to; on some PICs you can even get the interrupt to rotate between the CPUs each time it goes off.
Does this mean that interrupts happen with each CPU? I can't understand exactly above info. If interrupts happen to each core, I must take account of critical section for shared data on each interrupt service routine of the buttons.
If interrupts happen to each CPU, I don't have to take account of critical section for shared data. What is correct?
To sum up, I wonder How do interrupts in multi-core system? Is the interrupt line is connected to each core or CPU? So, should I have to take account of critical section for same interrupt?
your quote from google looks quite generic or perhaps even leaning on the size of x86, but doesnt really matter if that were the case.
I sure hope that you would be able to control interrupts per cpu such that you can have one type go to one and another to another.
Likewise that there is a choice to have all of them interrupted in case you want that.
Interrupts are irrelevant to shared resources, you have to handle shared resources whether you are in an ISR or not, so the interrupt doesnt matter you have to deal with it. Having the ability to isolate interrupts from one peripheral to one cpu could make the sharing easier in that you could have one cpu own a resource and other cpus make requests to the cpu that owns it for example.
Dual, Quad, etc cores doesnt matter, treat each core as a single cpu, which it is, and solve the interrupt problems as you would for a single cpu. Again shared resources are shared resources, during interrupts or not during interrupts. Solve the problem for one cpu then deal with any sharing.
Being an ARM each chip vendors implementation can vary from another, so there cannot be one universal answer, you have to read the arm docs for the arm core (and if possible the specific version as they can/do vary) as well as the chip vendors docs for whatever they have around the arm core. Being a Broadcom in this case, good luck with chip vendor docs. They are at best limited, esp with the raspi2. You might have to dig through the linux sources. No matter what, arm, x86, mips, etc, you have to just read the documentation and do some experiments. Start off by treating each core as a standalone cpu, then deal with sharing of resources if required.
If I remember right the default case is to have just the first core running the kernel7.img off the sd card, the other three are spinning in a loop waiting for an address (each has its own) to be written to get them to jump to that and start doing something else. So you quite literally can just start off with a single cpu, no sharing, and figure that out, if you choose to not have code on the other cpus that touch that resource, done. if you do THEN figure out how to share a resource.
I am using STM32F205RGT6 Cortex-M3 microcontroller and coding with IAR Embedded Workbench.
I plan to keep the microcontroller in a power saving mode most of the time except when an external component tries to either communicate via SPI (the STM32 microcontroller is meant to be a SP slave) or via USB.
One external compinent is connected via SPI (PB12-15) and PC is connected via USB (PA11-12).
The communication works fine - I have tested both the SPI as well as USB.
I figured that once I am done setting up SPI and USB I will call a power saving function and add the same function call at the end of interrupt service routines. I have found PWR_EnterSTANDBYMode and PWR_EnterSTOPMode (in stm32f2xx_pwr.h) both of which I tried using.
However with such arrangement I cannot establish any communication (SPI or USB) with the microcontroller.
Is there something extra that needs to be configured (for example which pins should wake the microcontroller up)?
Am I using wrong function? Or wrong header file?
Can you point me to an example resembling such case (I could not find anything similar on ST's website)?
Any constructive feedback would be welcome.
In the mean time I found the application note AN3430 (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00033348.pdf) which is somehow more digestible (only 38 pages) which gives an excellent overview on power saving in the microcontroller.
Since I don't have access to PA0-WKUP (the wake-up pin) I had to discard using stand-by. Seems that just a simple sleep mode in main loop - by calling __WMI(); - should lower current consumption enough in my case. I might consider stop mode if sleep mode isn't enough but I will have read fragments of datasheet on configuration of EXTI registers that the application notepoints to.