Search Results

Thanks for the tip, I was able to figure it out. Here is what I came up with. First, since the Apollo3 is a Cortex M4, it can detect if a debugger is physically present like this: Source Code (3 lines) Second, in my routine that puts the system to sleep, I always let the system sleep if there is no debugger. If there is a debugger, I only let the system sleep if there is no outbound data in the upbuffer: Source Code (4 lines)Now I get all my output at the right time.

Where would I find the Nordic source code that demonstrates how to do that? Maybe I can replicate it.

In case it wasn't obvious, here is sample output from two iterations. Source Code (28 lines)Lines 1 through 16 should get printed before the system goes to sleep for 4 seconds. Instead, only lines 1 through 11 get printed. Four seconds later, lines 12 through 28 finally get printed out along with the first part of the output from the next task iteration. The next iteration is also missing the last 5 lines of its own output, which come out at the start of the next iteration, and so on.

I am working with an Ambiq Apollo3 Cortex M4 processor on a SparkFun Artemis module using Segger Embedded Studio. I have a FreeRTOS program that performs a task every 4 seconds. The task takes roughly 100 mSec to run. When FreeRTOS has nothing to do, it puts the processor into a deep sleep mode, so most of the time my system is in deep sleep. The periodic task generates a bunch of RTT output as it runs. The odd part is that the last few lines of output get delayed, and don't show up until the ta…

I do not see that issue listed in the errata for my part [ATSAM3S4C rev A], but I suppose that the published list of errata will not cover everything. I suppose that the irony of my situation is that I just spent a bunch of time and effort specifically to make my task-management system 'tickless', and the workaround is to add back a 'tick'. But it certainly explains why I have not seen the issue before. Thank you very much for tracking down that issue. Your support is excellent!

I updated to 5.02f. I get the same error, but the error message is updated to saying that is is version 5.02f.

I have a home-brew co-routine task management system that uses a Cortex M3 _WFE() [Wait For Event call] to sleep in between system events that might cause tasks to run. I have been using this software for a couple years now on an Atmel SAM3S and a J-Link debugger with no problems. It is an event-driven mainloop shown here in a simplified form: Source Code (5 lines) After upgrading to Atmel Studio 7 and the latest J_Link V4.98e firmware for my JLink debugger, I now get very strange error messages…