I encountered the following issue while using Keil MDK 5 for STM32H743.
I had a communication problem with my SPI code and after a while I found out that it was due to the Periodic Windows Update.
When it is activated, it seems that the debugger is reading regularly the SPI data register, which reads the FIFO (so changes the state of the FIFO). Consequently when the software reads the FIFO, some bytes have been "lost" (or consumed by the debugger).
Is it an expected behaviour ? Do you know if it is due to Keil or to the STM32 ?
I don't fully understand how an access from the debugger to a register is working: I guess there is a read command sent over SWD but then, internally does the access to memory go through AHB / APB like for code executing on the CPU ?
Any registers that modify behaviour by being read (such as clearing status bits) can be problematic when debugging and the registers are shown in the debug window.
The best bet is to only look at the registers when you stop (close the DR window for the peripheral), and always be aware that you may clear status bits etc.
It is the way the processor works and nothing to do with the debugger.
It is a very common debug issue with serial comms etc.
if you have DR display in your watch window (or any other similar windows on the debugger screen) and you step through the code every time you step (or generally break) the data is read.
That is the only possible reason.
Related
I'm facing an unexpected problem with stm32f103c8. I'm programming the chip and after reset, it starts to run the program, but after a few seconds the microcontroller getting mixed up and stops running the program. After that when I try to reprogram the microcontroller, IDE(IAR EWARM) tells "target held in reset state".
It's very unusual issue because sometimes when I connect nRST pin directly to the VCC(3.3V), microcontroller runs program but unfortunately the current goes over 120mA and chip breaks down finally.
I'm using STM32CubeMX to generate the codes and my programmer is STLINK V2(clone), also tried Jlink V8.0(clone) but didn't change the result.
Could it be because of the clone programmers?
Can anyone help me solve this problem?
Thanks
Never connect nRST directly to VDD/VCC. This is a bi-directional input-output which must only ever be connected to an open-drain/open-collector signal. It can be pulled low externally or from within, it must never ever be pulled or driven high other than by the internal pull-up resistor.
When your debugger or programmer has finished programming the flash and wants to start running the new program then it requires to be able to pull this line low, which it might do externally if you connect this line to it in hardware, or else it has to be able to pull it low by software using the internal reset pulse-generator. If it does this and you have tied the line high externally then you are effectively shorting out your power supply, which is the cause of the over-current condition that you have observed.
Maybe the original problem is that your counterfeit ST-Link has its reset output configured as push-pull when it should be open-drain.
I would suggest that the easiest way to proceed is to leave the nRST line unconnected and configure your programming tool to use a software reset only.
I'm having trouble with i2c communication. In my i2c bus, i have 4 boards (STM32L4 Sensortiles) and sometimes one of them blocks the bus and the others stop communicating consequently. When I reset that one that blocks the bus, all boards starting working again.
In my debugs, this bug happened when HAL_I2C_GetState(&hi2c3) returns HAL_I2C_STATE_BUSY_RX, even my others i2c functions HAL_I2C_Slave_Receive_IT and HAL_I2C_Slave_Transmit_IT returns HAL_OK:
Any ideas what Im doing wrong? Thanks.
Using libraries like HAL leads to problems like this one. Why?
HAL users feel free from knowing your hardware as magic library will do everything for you.
HAL users usually do not know how the peripheral works and how to debug it.
HAL users do not bother to go through the magic HAL function to see what the problem is.
Posting some images form debugger will not help.
What you need to do:
Get even the cheapest logic analyzer (there are $10 on ebay) and record the communication. See if the slave keeps the clock or data line low. If yes toggle the clock pin 9 times to unblock the line
If nothing helps reset the I2C peripheral using RCC register (it has to be implemented on all connected boards).
I have been having an issue in my project with LWIP. I am using a ST32F4 MCU and running with no OS. The network seems to run fine, the protocols all work, but then (usually a day or two later) the stack just stops running. It seems to happen when trying to make a new connection, but I can't confirm that because I haven't been able to locate what is causing it in the code.
Has anyone else come across this issue? I think it may be the same as this guy.
Do you call any LwIP functions from any interrupt-handlers, like UART etc?
How do you feed packets in/out of LwIP? Directly via interrupt handlers, or do you push them in from your "main-loop" ?
Lock-ups can also be signs of double free, or use-after-free of pbufs.
I also experiences that one project was unstable with wierd random locks-ups when running at the top-rated frequency of the STM32. If I clocked my STM32 at 100MHz instead of 120MHz, all my problems went away....
I am working on a project using STM32F103 and I have finished development of the firmware. I use ST-Link Utility for downloading stuff to the microcontroller. When I activate read out protection on my chip, it stops working. And I need to protect my firmware. What is the problem?
Just a bit more info to the accepted answer:
From ST32F10XXX docs, section "2.4.1 Read protection":
The read protection is activated by setting the RDP option byte and
then, by applying a system reset to reload the new RDP option byte.
Note: If the read protection is set while the debugger is still
connected through JTAG/SWD, apply a POR (power-on reset) instead of a
system reset (without debugger connection).
Once the protection byte
has been programmed:
Main Flash memory read access is not allowed
except for the user code (when booting from main Flash memory itself
with the debug mode not active).
Pages 0-3 (for low- and
medium-density devices), or pages 0-1 (for high-density and
connectivity line devices) are automatically write-protected. The rest
of the memory can be programmed by the code executed from the main
Flash memory (for IAP, constant storage, etc.), but it is protected
against write/erase (but not against mass erase) in debug mode or when
booting from the embedded SRAM.
All features linked to loading code into and executing code from the embedded SRAM
are still active (JTAG/SWD and boot from embedded SRAM) and this can be used to
disable the read protection. When the read protection option byte is altered to a
memory-unprotect value, a mass erase is performed.
When booting from the embedded SRAM, Flash memory accesses through the code
and through data read using DMA1 and DMA2 are not allowed.
Flash memory access through data read using JTAG, SWV (serial wire viewer), SWD
(serial wire debug), ETM and boundary scan are not allowed
Unprotection
To disable the read protection from the embedded SRAM:
Erase the entire option byte area. As a result, the read protection code (RDP) will be
0xFF. At this stage the read protection is still enabled.
Program the correct RDP code 0x00A5 to unprotect the memory. This operation first
forces a Mass Erase of the main Flash memory.
Reset the device (POR Reset) to reload the option bytes (and the new RDP code) and,
to disable the read protection.
Note: The read protection can be disabled using the boot loader (in this case only a System Reset
is necessary to reload the option bytes). For more details refer to AN2606.
There's also a write protection on the chip, see the doc.
ADDED: STM32 readout protection has problems: https://blog.zapb.de/stm32f1-exceptional-failure/ so be aware.
You have to unlock the flash first. There should be a call in the STM32 StdPeriph library. My code looks something like this:
/* Read protect the flash. NEVER EVER set this to level 2. You can't
* write to the chip ever again after that. */
FLASH_OB_Unlock();
FLASH_OB_RDPConfig( OB_RDP_Level_1 );
if (FLASH_OB_Launch() != FLASH_COMPLETE)
{
err_printf("Error enabling RDP\n");
}
FLASH_OB_Lock();
RESOLVED
After much confusion and frustration, I finally got my hard disk to interrupt. :D It basically came down to the fact that I kept reading the status register instead of the alternate status register. A few other things were messed up to boot, but the point is my hard disk driver is finally starting to take shape. Now, for others I will leave the original post.
P.S. For further clarification, I didn't need to issue any sort of reset command. All I did was the following:
Select the device (didn't want to kill the Solaris OS on the other disk)
clear the nIEN bit in the DEVICE CONTROL register
issue an IDENTIFY DEVICE command***
Actually, I am not sure if the IDENTIFY DEVICE command is need because I left the lab happy before I could test the code without issuing the command. However, the main point is that I needed to be sure to read the alternate status register and have the nIEN bit cleared without the need for a reset. The BIOS apparently takes care of most stuff.
I am currently trying to write a disk driver for a hobby OS being developed at my school. I currently have routines to read/write data in the PCI configuration space and assembly routines to do port IO with the various registers defined by ATA/ATAPI-7. Now, my question is, specifically how will I get an IDE hard drive to start generating interrupts? I have been looking through all this documentation and is hasn't become clear to me what I am doing wrong.
Can someone explain exactly what causes an IDE hard drive to start generating interrupts? I already have an interrupts service routine ready to test, but am having difficulty getting the interrupts in the first place. Can this be accomplished through the ATA SOFT RESET?
Thanks!
UPDATE: Ok, I was able to get the secondary channel, an ATAPI CDROM to generate interrupts by setting the SRST bit in the DEVICE CONTROL register for a soft reset. This does not work for the hard disk on the primary channel. What I have noticed so far is that when I set the SRST bit for the HDD, it sets the BSY bit and leaves it set. From there I don't know what to do.
This reference should help you a fair bit: Kenos description of programming ATA/ATAPI.
The basic mechanism to enable interrupts is to clear nIEN in the DCR (Device Control Register):
nIEN: Drive Interrupt Enable bit. The enable bit for the drive interrupt to the host. When nIEN is 0 or the drive is selected the host interrupt signal INTRQ is enabled through a tri state buffer to the host. When nIEN is 1 or the drive is not selected the host interrupt signal INTRQ is in a high impedance state regardless of the presence or absence of a pending interrupt.
This www.ata-atapi.com is a good jumping-off point to find way more info about ATA/PATA/SATA/ATAPI than you want to know... Note that the official ATA-6/7/etc specs cost $$ from T13, though you can download current drafts of ATA-8 from them.
This link describes a few of the many ways ATA devices vary from the specs. (I used to write SCSI and ATA/ATAPI drivers for Commodore/Amiga, way back when, as well as help with qualifying drives - or more accurately, figuring out what idiocies drive makers had done.)
if this is just a hobby OS, why not use the BIOS interrupt (int 13h)? admittedly not as fast as direct disk access but safer for your hard drive (I've put a read head through a plate before messing with disk I/O).