I am trying to manually set the ISER0 and STIR registrs to invoke interrupt number 3 which is RTC Wakeup Interrup for educational purposes. Here is my code:
I step through the register contents, but somehow the code was not able to write to the ISER0 and STIR registers, as is shown below where i am trying to clear the ISER0 register.
Can someone please explain me what am i doing wrong here?
ISER has one bit for every exception, STIR takes exception number - 16.
In the second image you write 0 to the ISER register. That has no effect as described from both ARM architecture reference manual and STM32 M4 Programming Manual.
I would put a volatile on both register pointers declaration, but in this case I don't think it's an issue.
The issue is solved. Somehow, the stlink debug with openOCD was causing an issue with semihosting enabled to which i have no explanation for now. When I changed the debugging to STLink with SWV viewer, it worked ok...
Related
Upon instantiating a LowPowerTimer, like so:
LowPowerTimer* lowPowerTimer = new LowPowerTimer();
It crashes on my own target. It works 100% on the STM32F429-discovery evaluation board.
What could cause the problem? All other code runs perfectly. There are enough memory and flash. The micro is of the same family. Are there any prerequisites that I do not know of? The micro I'm using is the STM32F413RH with a 26MHz external crystal.
I use the mbed platform and code in C++, FWIW...
My first guess would be that you have not configured the lpticker clock source correctly. Do you have the same crystals as the evaluation board? See which clock source the lpticker is using there and see if it's missing on your final board.
In addition, what is crashing? Do you see a hard fault? Where does it originate from?
So what I found was that in the targets.json file I had to override the lse_available macro. The lse_available macro states that a low-speed external oscillator is connected to the micro - and then the Low Power Ticker would use that as its source. But if you set it to 'not connected', it uses other clock sources.
I'm doing an STM32 HAL course.
In the section "Direct Memory Access (DMA)", the interrupt doesn't get fired on completion of the DMA transfer.
In polling mode all works fine.
I use a Nucleo-F746ZG, my code is on github: https://github.com/bkht/STM32-HAL-DMA-Interrupt
What could I check to fix this?
When setting up the callback function, does it need to go before calling HAL_DMA_Init?
Or can it be done just before starting the DMA transfer with HAL_DMA_Start?
Also, I do see the & sometimes, referring to the function address, I tried it, but it didn't make a difference.
What should be used, & or not?
/* Setup callbacks, not sure this can be done without HAL_DMA_Init */
hdma_memtomem_dma2_stream0.XferCpltCallback = &XferCpltCallback;
Pulling #jacobq comment into an answer.
There is currently a bug in the CubeMX autogenerated code where the MX_DMA_Init() is called in the wrong order.
The proposed solution is to edit the ioc file, where it lists the function order.
This is needed because the CubeMX software (in Project Manager > Advanced Settings) locks the position of the MX_DMA_Init generated function call unhelpfully!
I'm using a cortex m4 with freertos and i receive the following error
Err: -110595: Hardfault occurred!
I have no idea what to check.
The meaning is CRIT_ERR_HARD_FAULT but how do i trace it back?
It's always tricky and there is no common checklist what should be checked to give you 100% chance for quick success here.
Anyway checking several registers' values should give you enough information to proceed. To do it, you have to know what's the procedure of entering an exception - especially what's happening with core registers and the stack: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html
If you can use online debugging, put a breakpoint in hard fault handler and check the following:
stacked PC - as written in the article above, on exception entry ARM core automatically pushes registers r0,r1,r2,r3,sp,lr,pc and psr on stack. Look it up to check where the program was before execution
current LR - to verify if you came from Thread mode (normal program execution) or another interrupt compare current LR with the table in the article
ISR_NUMBER in IPSR being part of current PSR - to verify whether in fact hard fault exception occurred or your hard fault handler is used as a sink for all types of faults
CFSR and other fault related registers in SCB - it should give you more information what's exactly caused the problem. Since SCB is a peripheral block, it's not visible in most IDEs by default. Install peripheral plugin or simply access addresses via memory inspection window http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Cihcfefj.html
If you're unable to do online debugging, you'll need a feature which will dump these registers somehow.
Good luck!
Are your HardFault handlers strongly defined? If you have the ability to connect a debugger and the fault is reproducible you can set a breakpoint in your fault handler and check the stack trace for possible areas of interest.
Alternatively, this guide provides a highly portable and useful method of diagnosing hard faults and gathering information post fault for the ARM processor.
Sorry - this is long! I'm sure I'll get some TL;DRs. :/
I'm not at all new to the world of Cortex M3/4; I have encountered plenty of hard fault errors in the past and, without exception, they have been due to stack overflow on FreeRTOS. However, in this case, I'm really struggling to track down a hard fault on a system that has someone else's old code that I have slightly modified.
I have a system with an LCD and touch screen. We have new hardware, which is almost identical to the old hardware other than it changing from an LPC1788 to a drop-in equivalent LPC4088 and the touch screen being I2C rather than SPI.
I'm using Keil uvision (which is new to me) with an NXP4088 which is an M4 core and Keil RL-ARM RTOS (also new to me) which is using C/C++ hybrid, the C++ also not something I have much experience with. On top of this, there is Segger emWin (which I've never used) closed source code where it always seems to be crashing. It will render a few screens, read the touch screen buttons etc and then fall over. Sometimes it falls over immediately though.
I have followed this:
http://www.keil.com/appnotes/files/apnt209.pdf
I have attached a picture of the debugger/IDE when it crashes below (click to enlarge).
When it crashes, the highlighted green task in the OS is, without exception, ApplicationTask (which I have not modified).
If I am reading the info correctly the Keil uvision debugger tells me that the stack being used was the MSP stack which is at address 0x20003238. There's a memory dump below:
If I understand correctly, this means that R0, 2, 3 and 12 are 0, the program counter is at 0 as are LR and PSR. However, this goes against what's in the Call Stack + Locals window in the first picture. If I right click on the 0x00005A50 underneath ApplicationTask:4 and choose caller code, it itells me it is
BL.W GUI_ALLOC_UnlockH
Which is in the emWin binary blob I think.
However, if I look at 0x20001B60 (which is the PSP stack value) as below:
That seems to tally up much better with what the Call Stack + Local Window tells me. It also seems to tell me that it's crashing in emWin and extensive Googling shows that Segger always completely wash their hands of any possibility their closed source code could be at fault. To be fair, it's unlikely as it's been working OK until I modified the code to use an I2C touch screen interface rather than SPI. However, where it's crashing (or seems to be) is nothing to do with the code I have modified.
Also, this window below:
Gives the BFAR address as 0xF00B4DDA and the memory manager fault address as 0xF00B4DDA. I don't know whether I should be interpreting this as to being the issue.
I have found a few other posts around the web, including one staggeringly similar one to this here on Stack Overflow (but all have no solution associated with them) where people have the same issue.
So, my questions are:
Am I reading this data correctly and understanding the Keil document I linked to? I really feel I must be missing something with this MSP/PSP issue.
Am I using the caller code function with uvision correctly? The bit where I right click on Call Stack + Locals' address below ApplicationTask:4 and it always seems to take me to some Segger code I can't examine and surely isn't what's at fault.
Should I really be reading the issue as a bus fault address with it trying to read from or write to 0xF00B4DDA which is reserved space?
I tried implementing a piece of code such as this:
https://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/
But that just stops the whole system running properly and ends up in at BKPT instruction in some init code. On top of this, I am not convinced this kind of thing would tell me any more than uvision does, other than it showing me slightly faster and with zero effort. Am I right in this latter assumption?
I'm relatively new in ARM Cortex M4 series micro-controller.
When I'm trying to debug a simple project(blinky which easily just blinks a led on and off) using KEIL 5 simulator, I get an error like this:
* error 65: access violation at 0x400FE608 : no 'read' permission
* error 65: access violation at 0x400FE608 : no 'write' permission
I searched on internet for a solution, and I get this one:
http://www.keil.com/support/docs/814.htm
But actually it is not easy and not logical to mention all the addresses to which I want to access in my whole code like the method mentioned above.
could anybody suggest something else for me please?
(Actually I get this error with all projects which I intended to simulate so I can't simulate anything).
Here is the simple code which I have been using:
#define GCGPIOR (*((int*)0x400FE608))
int main(void)
{
GCGPIOR |= 0x20;
return 0;
}
and I am using this mc: TM4C1294NCPDT
I have a similar problem with KEIL V5, in a CMSIS project with LPC1768 microcontroller.
When debugging with real microcontroller as target, everything works fine. Debugging with simulator as target, when CMSIS tries to initialize the System core clock I get:
*** error 65: access violation at 0x400FC1A0 : no 'write' permission
Is this really sample code from the chip vendor? The definition of GCGPIOR should be volatile.
#define GCGPIOR (*((volatile int*)0x400FE608)))
Have you selected the correct device in the simulator/project configuration? Have you installed the Keil::TM4C_DFP device package and are you using the correct device configuration?
The problem appears to be that the memory map used by the simulator is automatically set up from the linker memory map. If you make direct memory mapped I/O accesses not known to the linker, then it will raise an exception (when this mechanism detects a bug in your code you may be glad of that - it is not a bug in uVision - it is intentional behaviour).
If the MAP command or dialogue did not work for you, Occam's razor suggest to me that you did not perform the operation correctly. You should map the entire I/O region given in your part's data sheet or user manual. It may work I suppose if you define the I/O region in the linker scatter file - but that may be getting a bit too complicated.