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!
Related
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...
How do you debug an RTOS application? I am using KEIL µVision and when I hit debug, the program steps through the main function until the function that initializes the RTOS kernel and then you can't step any further. The code itself works though. It is not mine btw, but I have to work on it. Is this normal behavior with RTOS applications or is this related to the program?
Yes, this is normal. You need to set breakpoints in the source code for the tasks that were created in main(): the only purpose of main() in a FreeRTOS application is to :
initialize the hardware,
create the resources (timers, semaphores...) and tasks your application will need,
start the scheduler
The application should never return from vTaskStartScheduler() if they were enough resources available.
Put break-points at the entry point of each task you need to debug. When you step the over the scheduler start (or simply run) the debugger will halts at the first task that runs. When that task blocks, some other task will be selected to run according to the scheduling rules.
Generally when debugging and you reach a blocking call, step-over it, other tasks may run and the debugger will stop at the next line only when the task becomes ready (depending on the nature of the blocking call). Often you will want to predict what task will run as a result of the call, and put a breakpoint in that task. For example if you issue a message send, you might place a breakpoint after the message receive call of the receiving task.
The point is you cannot "step-through" a context switch unless you have the RTOS source or do it at the assembler level, which is seldom useful or productive, and will not work for preemption.
You get a somewhat better RTOS debug experience and tool support in Keil if you use Keil's own RTX5 RTOS rather then FreeRTOS, but all of the above remains true.
Yes, this is an expected behaviour. The best way to debug a RTOS application is to place breakpoints at all tasks, key function entry points and step debug.
The debugger supports various methods of single-stepping through an application as in below link.
http://www.keil.com/products/uvision/db_exe_step.asp
Typical challenges in debugging RTOS application can be dealing with interrupt handling, synchronization issues and register/memory corruption.
Keil µVision's System Analyzer enables one to view the program execution time frame, status of each thread. It shall also help in viewing interrupts, exceptions if tracer is enabled.
in my project i injected a DLL(64-bit Windows 10) in to a external process with Manual-map & Thread-hijacking and i do some stuff in there.
In current state i use "RtlCreateUserThread" to create a new thread and do some extra workload in there to distribute it for better performance.
My question is now... Is it possible to access other threads from the current process (hijack it) and add your own workload/code there. Without creating a new thread?
I didn't found anything helpful yet in the internet and the code i used and modified for Thread-hijacking seems to only work for a DLL file. Because i am pretty new to C++ i am still learning i am already thankful for any help.
(If you want to see the source for injector Google GHInjector your find the library on github.)
It is possible, but so complicated and may not work in all cases.
You need to splice existing thread's machine codes, so you will need write access to code page memory.
Logic:
find thread id and thread handle, then suspend thread with SuspendThread WINAPI call
suspended thread can be in wait state or in system DLL call now, so you need to analyze current execution stack, backtrace it and find execution address from application space. You need API functions StackWalk, and PDB files in some cases. Also it depends on running architecture (x86, amd64, ...). Walk through stack until your EIP/RIP will not be in application memory address space
decode machine instruction (it will be 'call') and splice next instructions to your function call. You need to use __declspec(naked) declared function or ASM implemented one for execute your code and replaced instructions.
ResumeThread
This method may work only once because no guarantees that application code is executed in loop.
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.
Basically, how can I make sure that in my module, a specific process is current. I've looked at kick_process, but I'm not sure how to have my module execute in the context of that process once kicking it into kernel mode.
I found this related question, but it has no replies. I believe an answer to my question could help that asker as well.
Note: I am aware that if I want the task_struct of a process, I can look it up. I'm interested in running in a specific context since I want to call functions that reference current.
Best way i have found to do anything in the context of a particular process in the kernel, is to sleep in process context(wait_* family of functions) and wake up that thread and do whatever needs to be done in that context. This would ofcourse mean you would have to have the application call into the kernel via IOCTL or something and sleep on that thread and wake it up whenever you need to do something. This seems to be a very widely used and popular mechanism.