I am working on a project where I connect JTAG to SOC and debug the image on the SOC using the JTAG. The image also runs with watchdog timer that runs during core initialization, and which needs to be reset periodically to prevent the board being reset.
Now for my own understanding I was wondering how JTAG connects to the image and lets us set breakpoint during initialization without worrying about the watchdog timer. I have seen the image running for a long time, under JTAG, without the board being reset by watchdog.
I tried talking to multiple people in my team to try understand this but none of the explanations were satisfactory. Can somebody please explain what exactly is going on in terms of both JTAG and watchdog timer.
The answer depends on the type of SoC you are debugging since the watchdog function normally is an independent function inside or outside the SoC, and I don't see a direct relation to the JTAG interface of the CPU.
Still, some controllers do implement features to stop the watchdog time while the CPU is stopped by a breakpoint. For example, STM32F1 controllers offer the DBGMCU_CR register where you can (even through the debugger) configure whether the watchdog timer shall continue running while the core is halted.
Related
I am a beginner in RTOS programming.I have a query regarding the same.
Query:I understand that context switching happens between various tasks as per priority assigned. I wanted to know how exactly does a higher priority task interrupts a low priority task technically? Does each task is assigned to hardware interrupt pin so that whenever micro-controller is interrupted on that pin by external hardware,the specific task is processed provided it is assigned higher priority when compared to the task that is presently being processed? But practically speaking if there are 128 tasks present in the program it might require 7 hardware pins reserved for interrupts. What is the logic I am missing?
I recommend to read the pretty good docs on https://www.freertos.org e.g. RTOS Fundamentals
I’m sure this will provide a good overview and related details.
Besides that you’ll find out that usually you don’t need external hardware pins to run a multitasking OS.
Free RTOS uses only sys_tick/os_tick hw-interrupt for context switching. This is high precision periodic interrupt configured on any underlying controller
for example on Cortex M:
https://www.keil.com/pack/doc/CMSIS/Core/html/group__SysTick__gr.html
In the interrupt handling of this, FreeRTOS schedular switches the tasks based on the Ready Queue Task list and its priorities.
Hello i have just started using FreeRTOS with STM32. I understand the concept of synchronisation between Tasks or Threads using Semaphores. But what i really dont get is the use of the Semaphores/Mutexes with the Interrupt Service Routine ISR. Why would i use xSemaphoreGiveFromISR() instead of just using xSemaphoreGive() while both of them are mainly used for sync purposes not to interrupt. Also what is the difference between software timers and Interrupts?. I know when and how i should use Interrupts but when would i need to use software timers?
If you dig into the sources you‘ll see the difference between the normal vs. *FromISR API. There are a few more of those. It’s mainly an optimization to minimize execution time in ISRs (if supported by the MCU used) because ISRs should be kept as short as possible.
Also the ISR (calling) context is different to normal task context and the *FromISR API takes care of this.
It’s an implementation detail - just follow the documented rules and you’ll be fine :)
Basically software timers are used to support a couple/many timers using a single HW timer. Often software needs a number of simultaneously running timers e.g. to trigger a number of periodic jobs/actions with differing periods, but HW resources (timers) are limited.
This also applies to the FreeRTOS timer feature using the FreeRTOS systick which usually runs anyway.
Interrupts in general are a different thing. They’re a way how peripheral HW can interact with an connected processor where an application is running.
Well, for instance a HW timer configured accordingly fires up an (HW) interrupt to trigger a software via an ISR to do something on that event.
See also the recommended and comprehensive FreeRTOS documentation.
I'm using the Ravenscar profile to build an application that utilizes tasks.
As a simple example, I have one task that has a barrier such that it only executes when the barrier is True.
However, I've noticed that if the main control thread is executing, and then the barrier is set to true (thus released) the task blocks execution of the main thread until the barrier is closed again.
I'm working on a NRF52840 chip. I should note, whenever I target the application (with no modifications) to Native this problem doesn't happen and the tasks do not block execution.
Is there something I need to do in order to enable parallel execution for the ravenscar (full) RTS on embedded devices?
Some Additional Color: If I add a delay to the loop of the task, it indeed allows the main control thread to run.
Is this perhaps an issue with the priority ceiling protocol? The processor on board only has one core so I'm wondering if that is perhaps the problem -- that is, the task doesn't allow the main task to preempt unless it's sleeping.
What are the relative priorities of your main program and your task? I don’t know about AdaCore’s runtimes, but it’s at least possible that the environment task (which executes the main program) might have lower priority than your task.
What does your task do while it’s enabled? If it just spins (from the runtime’s point of view - i.e. no delays or calls on protected entries), then once it gets onto the ready queue, why should it relinquish it? If there’s only one core, no other task of the same or lower priority can execute.
The NRF52840 is built around an ARM M4 chip, which has a single core, whereas your desktop very likely has multiple cores.
The way to set the main program’s priority is, for example,
with System;
procedure T
with Priority => System.Default_Priority - 1
is
...
As Simon pointed out the issue is with priority -- the fix, as he pointed out is to assign a priority to my task.
On my system (GNAT 2012 from AdaCore) the default priority is 15; setting the tasks to something reasonable like 5 seems to fix the issue.
There is a FreeRTOS library for Arduino, purported to even run on the UNO.
I'm trying to understand the inner workings of how a multi-tasking operating system can run on such limited hardware. I understand the principles of task scheduling/switching, but how does the kernel actually suspend a task in order to execute another one? How does it interrupt (and then later resume) the currently-executing code?
My guess is that a scheduled ISR (timer) directly modifies the stack to change the instruction pointer, but if it does this, it needs to make a copy of the stack and registers before switching tasks, then restore the current task's stack/registers before resuming execution. I'm not clear on how it would do this.
Can the FreeRTOS kernel switch tasks in the middle of, for example, a Serial.println() function call, (or any call that doesn't include cli()) and if so, how does it do this?
Thanks for any clarification.
My guess is that a scheduled ISR (timer) directly modifies the stack to change the instruction pointer, but if it does this, it needs to make a copy of the stack and registers before switching tasks, then restore the current task's stack/registers before resuming execution. I'm not clear on how it would do this.
Your guess is correct. If you look at port.c you will see, that the FreeRTOS makros portSAVE_CONTEXT and portRESTORE_CONTEXT are pushes respective pops all registers of the current running task to perform the task switch. Furthermore the watchdog timer interrupt is used to run the scheduler.
As long this watchdog timer is enabled and is triggerd, task switches can happen any time. So a switch can also happen during any function call like Serial.println. This implies that if you call this function from several task you will sooner or later corrupt your output of the serial stream.
I am using 3 micro-controller on a board.
Main micro, gateway micro and safety micro;
name suggest the associated applications.
Internal watchdog exist for all three, but I need to have an external supervision so as not to have a buggy timer code nullifying the effect of internal watchdog. Also to keep the BOM cost low, so can use just 1 external watchdog.
Propose to use the following strategy:
Main microcontroller: We plan to have the internal watchdog and as well an external watchdog for this.
Safety Microcontroller: We plan to have internal watchdog and as well monitoring over SPI by Main microcontroller.
Gateway Microcontroller: We plan to have internal watchdog and as well monitoring over SPI by Main microcontroller.
One issue with this is - EMI or noise issues over line causing SPI corruption and hence false RESET from main micro.
Has anybody faced similar challenge? Any suggestions for this?
Many Thanks for your help!!!!
Not knowing the specifics of your application, it is not possible to give you a definitive answer. The way you would normally solve this sort of problem is to do a failure mode and effects analysis. Essentially you list out all the parts of your system and then brainstorm all the possible failure modes you think could happen. EMC would be one of them. You then estimate a probability that each failure mode will occur and assign a severity to it in the event that it does occur. Multiplying these out will allow you to identify the areas that carry greater impact and need extra protection. When all the failure modes have a severity x risk value below a threshold set by your application, you will have a 'valid' solution.
Not doing a thorough analysis like this means you may very well put all your effort into defending the front door while leaving the back door unlocked.