I'm using FreeMaster v220.127.116.11 [Jan 20 2020 14:46:31].
In graphing a variable (specifically the number of msec remaining for a second), I noticed some glitch which shouldn't be there. My code simply decrements this 2-byte variable by 1 in one place in the whole app with the following (9S08) instruction sequence:
and reloads it when it becomes zero, again with STHX.
So the writes are guaranteed to be atomic. But, looking at the graph, I see those small spikes (3rd and last slopes) which do not make sense. They appear randomly, not in fixed distances.
I have checked my code and cannot find any issue with it. Plus, the date/time clock (which depends on this variable) does not seem to go either too fast or too slow over a long period (many days).
So, before I assume this is a bug in my code somewhere, I have to check with you in case it's an issue with FreeMaster.
So, is it possible that FreeMaster somehow messes it up?
For example, could it be it does not read the 2-byte value atomically with respect to the CPU writes? (Perhaps a limitation of BDM, I don't know.)
The graph below is set to the fastest possible reads/updates. (I have tried with slower ones, with no difference.)
P.S. I forgot to mention I use P&E Micro's Cyclone PRO with Ethernet connection.
I'm not 100% sure about this, but I think that LDHX/STHX are only atomic with regards to instruction fetching, not to the BDM access. This means, that you can rely on the access "atomicity" when executing a code and processing interrupts (ISR will never see such a glitched value), but you may see the glitches when memory is accessed directly via BDM.
I'm afraid that there is no protection against such spikes with BDM direct memory access. The only way would be to use Serial or CAN protocols to communicate between FreeMASTER and a driver in the S08 application.
I will try to consult this issue with experts on the S08 architecture.
UPDATE: Due to various serious instability issues with the FreeMaster v3.x (i.e., it crashed and not even a PC restart or re-installation would bring it back; saved only by Windows Restore to go back to before the initial installation) I went back to using v2.5 and I noticed the following behavior difference.
As you can see, compared to the previous graph, using the exact same settings as before, the problem is much more intense with a lot more spikes, and often twice per slope.
This leads me to assume that at least part of the problem is FreeMaster software related. Whatever improvements were made from v2.5 to v3.x to reduce those spikes could possibly be improved even further to completely eliminate this problem.
I just thought maybe this is something to let the FreeMaster developers know about.
I'm sorry for the issues you observe with version 3.0. Would it be possible for you to reach out to me directly by email and spend some time to analyze the problems?
FYI: the version 3.0.1 brings the latest version of P&E Micro BDM interface libraries. I'm discussing this "spikes" issue internally, I will let you know if there is any outcome of the discussion.
I got a feedback from experts on the S08/BDM architecture and also from P&E directly. They have confirmed that BDM direct memory access runs asynchronously to CPU read/write cycles. There is no way the spikes could be eliminated using a direct-access BDM plug-in.
Explanation for less spikes observed when using the latest version of DLLs: the later version has somewhat improved performance during the BDM communication so the probability of meeting the concurrent CPU write operation is smaller.
Conclusion: serial communication driver running on target MCU needs to be used to make sure the 16-bit or larger variable values are read atomically.
There is a FreeMASTER Communication Driver available for download at www.nxp.com/freemaster home page. It is an older (v2) version of the driver which also had a support for S08JM60 MCU. Please give it a try, it should be fairly straightforward to port it to other S08 parts.
The new v3 driver is only available for Kinetis, LPC, i.MX-RT and other CortexM-based parts as part of MCUXpresso SDK package and other SDKs. The v3 is not currently available for S08.