I'm using a cortex-a9 based design ( Altera Cyclon-V ) with a pl310 l2 cache controller.
When I'm enabling the "parity enabled" in the PL310 AUX register, I get failures ( interrupt indicating cache parity issue ) .
When I'm keeping Parity disabled (default value) system runs fine, no error\abort of bad data.
Any ideas why this might happen?
A few things that you should check up on is errata for the device that you are using and any specific recommendations on the operating frequency of the CPU to use certain features.
Early version of PL310 had a few bugs around the parity feature and a quick search also turns up the following document from Altera for the Cyclon-V devices. It recommends certain operating frequencies when using the ECC feature and the issue that you are seeing could be similar.
Parity is one way of checking that the memory locations have not been corrupted. With parity disabled, then you will not get errors or aborts, as nothing is checking the data.
With parity enabled, you have two potential causes of the aborts;
The memory system you have connected the cache controller to does not perform the parity checking the same way as the controller expects (or possibly not at all!)
You have an actual problem with the cache memory.
If you have the first problem, you need to decide if it is important and if so, configure, or implement (or buy!) a cache controller that works the way your system needs it to.
If you have the second problem, well, at least you know about it now, which you wouldn't have with parity disabled. It still needs fixing though!
Related
I'm working on one of Freesacle micro controller. This microcontroller has several reset sources (e.g. clock monitor reset, watchdog reset and ...).
Suppose that because of watchdog, my micro controller is reset. How can I save some data just before reset happens. I mean for example how can I understand that where had been the program counter just before watchdog reset. With this method I want to know where I have error (in another words long process) that causes watchdog reset.
Most Freescale MCUs work like this:
RAM is preserved after watchdog reset. But probably not after LVD reset and certainly not after power-on reset. This is in most cases completely undocumented.
The MCU will either have a status register where you can check the reset cause (for example HCS08, MPC5x, Kinetis), or it will have special reset vectors for different reset causes (for example HC11, HCS12, Coldfire).
There is no way to save anything upon reset. Reset happens and only afterwards can you find out what caused the reset.
It is however possible to reserve a chunk of RAM as a special segment. Upon power-on reset, you can initialize this segment by setting everything to zero. If you get a watchdog reset, you can assume that this RAM segment is still valid and intact. So you don't initialize it, but leave it as it is. This method enables you to save variable values across reset. Probably - this is not well documented for most MCU families. I have used this trick at least on HCS08, HCS12 and MPC56.
As for the program counter, you are out of luck. It is reset with no means to recover it. Meaning that the only way to find out where a watchdog reset occurred is the tedious old school way of moving a breakpoint bit by bit down your code, run the program and check if it reached the breakpoint.
Though in case of modern MCUs like MPC56 or Cortex M, you simply check the trace buffer and see what code that caused the reset. Not only do you get the PC, you get to see the C source code. But you might need a professional, Eclipse-free tool chain to do this.
Depending on your microcontroller you may get Reset Reason, but getting previous program counter (PC/IP) after reset is not possible.
Most of modern microcontrollers have provision for Watchdog Interrupt Instead of reset.
You can configure watchdog peripheral to enable interrupt , In that ISR you can check stored context on stack. ( You can take help from JTAG debugger to check call stack).
There are multiple debugging methods available if your micro-controller dosent support above method.
e.g
In simple while(1) based architecture you can use a HW timer and restart it after some section of code. In Timer ISR you will know which code section is consuming long enough than the timer.
Two things:
Write a log! And rotate that log to keep the last 30 min. or whatever reasonable amount of time you think you need to reproduce the error. Where the log stops, you can see what happened just before that. Even in production-level devices there is some level of logging.
(Less, practical) You can attach a debugger to nearly every micrcontroller and step through the code. Probably put a break-point that is hit just before you enter the critical section of code. Some IDEs/uCs allow having "data-breakpoints" that get triggered when certain variables contain certain values.
Disclaimer: I am not familiar with the exact microcontroller that you are using.
It is written in your manual.
I don't know that specific processor but in most microprocessors a watchdog reset is a soft reset, meaning that certain registers will keep information about the reset source and sometimes reason.
You need to post more specific information on your Freescale μC for this be answered properly.
Even if you could get the Program Counter before reset, it wouldn't be advisable to blindly set the program counter to another after reset --- as there would likely have been stack and heap information as well as the data itself may also have changed.
It depends on what you want to preserve after reset, certain behaviour or data? Volatile memory may or may not have been cleared after watchdog (see your uC datasheet) and you will be able to detect a reset after checking reset registers (again see your uC datasheet). By detecting a reset and checking volatile memory you may be able to prepare your uC to restart in a way that you'd prefer after the unlikely event of a reset occurring. You could create a global value and set it to a particular value in global scope, then if it resets, check the value against it when a reset event occurs -- if it is the same, you could assume other memory may also be the same. If volatile memory is not an option you'll need to have a look at the datasheet for non-volatile options, however it is also advisable not to continually write to non-volatile memory due to writing limitations.
The only reliable solution is to use a debugger with trace capability if your chip supports embedded instruction trace.
Some devices have an option to redirect the watchdog timeout to an interrupt rather then a reset. This would allow you to write the watchdog timeout handler much like an exception handler and dump or store the stack information including the return address which will indicate the location the interrupt occurred.
However in some cases, neither solution is a reliable method of achieving your aim. In a multi-tasking environment or system with interrupt handlers, the code running when the watchdog timeout occurs may not be the process that is causing the problem.
I am learning embedded systems on the ARM9 processor (SAM9G20). I am more familiar with procedural programming for general purpose. Thus what I am doing is going through the data sheet and learning what registers there are and how to manipulate them.
My question is, how do I know when the computer reset? I know that there is a Reset Controller that manages resets. A register called the Status Register (RSTC_SR) stores the source of the reset. Do I need to keep periodically reading this register?
My solution is to store the number of resets in the FRAM (or start by setting it to 0), once a reset happens, I compare this variable with the register value in my main function. If the register value is higher then obviously it reset. However I am sure there is a more optimized way (perhaps using interrupts). Or is this how its usually done?
You do not need to periodically check, since every time the machine is reset your program will re-start from the beginning.
Simply add checks to the startup code, i.e. early in main(), as needed. If you want to figure out things like how often you reset, then that is more difficult since typically (no experience with SAMs, I'm an STM32 type of guy) on-board timers etc will also reset. Best would be some kind of real-world independent clock, like an RTC that you can poll and save the value of. Please consider if you really need this, though.
A simple solution is to exploit the structure of your code.
Many code bases for embedded take this form:
int main(void)
{
// setup stuff here
while (1)
{
// handle stuff here
}
return 0;
}
You can exploit that the code above while(1) is only run once at startup. You could increment a counter there, and save it in non-volatile storage. That would tell you how many times the microcontroller has reset.
Another example is on Arduino, where the code is structured such that a function called setup() is called once, and a function called loop() is called continuously. With this structure, you could increment the variable in the setup()-function to achieve the same effect.
Whenever your processor starts up, it has by definition come out of reset. What the reset status register does is indicate the source or reason for the reset, such as power-on, watchdog-timer, brown-out, software-instruction, reset-pin etc.
It is not a matter of knowing when your processor has reset - that is implicit by the fact that your code has restarted. It is rather a matter of knowing the cause of the reset.
You need not monitor or read the reset status at all if your application has no need of it, but in some applications perhaps it is a useful diagnostic for example to maintain a count of various reset causes as it may be indicative of the stability of your system software, its power-supply or the behaviour of the operators. Ideally you'd want to log the cause with a timestamp assuming you have an suitable RTC source early enough in your start-up. The timing of resets is often a useful diagnostic where simply counting them may not be.
Any counting of the reset cause should occur early in your code start-up before any interrupts are enabled (because an interrupt may itself cause a reset). This may require you to implement the counters in the start-up code before main() is invoked in cases where the start-up code might enable interrupts - for stdio or filesystem support fro example.
A way to do this is to run the code in debug mode (if you got a debugger for the SAM). After a reset the program counter(PC) points to the address where your code starts.
I'm trying to temporarily mask all interrupts of a Cortex-M3, with only having access to the debug port. I can read and write the memory freely, which so far has been sufficient for accessing processor registers.
My best bet so far was writing 1 to one of the core registers (either PRIMASK or FAULTMASK), and disabling all interrupts that way. The problem is, I can't seem to access them. According to the ARM infocenter, I can use the DCRSR to select core registers, and then read/write them via the DCRDR. However, the infocenter page seems to imply, that there is no way to access the interrupt mask registers (PRIMASK, FAULTMASK and BASEPRI).
I did find a different source, namely the Definitive Guide to the ARM Cortex-M3, which shows on page 244, that the DCRSR can indeed be used to access the special registers, by writing 0b10100 to it. I tried that too, and the value I read from the DCRDR afterwards seemed nothing like what you would expect from the special registers (reserved values were set to 1s or 0s randomly, the first bit of FAULTMASK was 1, yet interrupts seemed to work fine). I still tried setting the first bit of the supposed PRIMASK to 1, in hopes of disabling the interrupts, but to no avail. It seems that the infocenter was right, and the DCRSR can NOT be used to access all special registers.
My question is, what other way is there, to access the interrupt mask registers from the debug port? Is there a direct memory address at which they are stored, or some different register that provides access to them?
Any help is greatly appreciated.
I have a project using ARM Cortex M4 with scaling CPU frequencies dependent on the workload. I would like to use the WWDG because it allows a lot more options like interrupt on watchdog. Question is: is there any standard workaround for variable time length CPU tick?
There are very different solutions for that. Which to choose depends on your setting and your aaplication (more precise on its criticality). If the WD is used only to detect a stuck in an uncritical application, i.e., no serious danger of hurts to human, animals, or expensive material damage, then a normal WD with relaxed timing is absolutely sufficient. If the aplication is critical and you expect some serious misbehaviour in case of underrunning a lower time limit, then a WWDG can be used.
So I have two possible solutions in mind, one simple and one complex; which one is best for your use case depends on what you require for your system (I cannot judge as you didnt tell on what kind of system you are working). The first solution would be to configure the WWD in a way that the limits are fullfilled with any of the settings. So the configuration is quite relaxed but sufficient for many use cases. So you dont have to take care for the dynamic switching of clock frequencies.
The more complex solution is to measure the time between to clock changes and determine the target time till the next WD serve with the newly selected frequency. When no more change happens in between, then the WD will beserved at that time. Otherwise you take the intervall with the latest frequency in account and calculate the next relative time stamp when the WD has to be served. But it depends on the timing you require if this is can be realized or not. If your timing is very tough (e.g, <1ms), then this would not realy be a viable option. But on the other hand, if the calculation is complex, you will obtain a simple challange response WD that checks the health your ALU in addition to the timing.
Im using an ARM926EJ-S and am trying to figure out whether the ARM can give (e.g. a readable register) the CPU's cycle-counter. I guess a # that will represent the number of cycles since the CPU has been powered.
In my system i have only Low-Res external RTC/Timers. I would like to be able to achieve a Hi-Res timer.
Many thanks in advance!
You probably have only two choices:
Use an instruction-cycle accurate simulator; the problem here is that effectively simulating peripherals and external stimulus can be complex or impossible.
Use a peripheral hardware timer. In most cases you will not be able to run such a timer at the typical core clock rate of an ARM9, and there will be an over head in servicing the timer either side of the period being timed, but it can be used to give execution time over larger or longer running sections of code, which may be of more practical use than cycle count.
While cycle count may be somewhat scalable to different clock rates, it remains constrained by memory and I/O wait states, so is perhaps not as useful as it may seem as a performance metric, except at the micro-level of analysis, and larger performance gains are typically to be had by taking a wider view.
The arm-9 is not equipped with an PMU (Performance Monitoring Unit) as included in the Cortex-family. The PMU is described here. The linux kernel comes equipped with support for using the PMU for benchmarking performance. See here for documentation of the perf tool-set.
Bit unsure about the arm-9, need to dig a bit more...