My company uses the 68HCS12 architecture (specifically the mc9s12dg128/mc9s12dg256 if it matters) with the NOICE12 debugger with the PE Universal Multilink. However, our programming speeds are rather long (about 75 seconds for our larger programs) and, to experiment, we recently bought a PE Universal Multilink FX (we've been using the PE Universal Multilink standard model for the last decade or two) with the hope that it would decrease this wait time. Unfortunately there was no significant improvement in speed (if any). After reading similar problems on this forum (specifically https://www.pemicro.com/forums/forum_topic.cfm?forum_id=8&forum_topic_id=6236#c17045) my guess is that we didn't see significant improvement for the same reason this person didn't: the BDM protocol bottleneck for our 68HCS12.
Since the FX didn't work for us, we're trying to figure out what other steps we could take to improve our load speeds and we're considering either the PROG12Z or the Cyclone FX (and/or the LC if applicable). It seems that we could get a not insignificant improvement in programming speed by buying the PROG12Z (for the PLL optimization reason mentioned in the above post). However the Cyclone FX provides a wealth of new options and flexibility and seems to provide dramatic speed increases (at least for ARM architectures). Yet, given our experience with the Multilink FX (which is understandable with our relatively outdated hardware), we wanted to reach out and confirm that the Cyclone FX would provide a significant speed increase for the 68HCS12 as well or if you would recommend the PROG12Z instead for our hardware?
Greetings,
You are correct that the Multilink FX will not provide any performance improvement compared to the Multilink Universal (non-FX) due to the BDM protocol. Another bottleneck you are facing is the need to use PROG software with USB protocol. This is where the cyclone can remove that bottleneck. If you set up cyclone's standalone programming and store your project inside the cyclone, then you can remove the USB and PROG software bottlenecks.
However in the end, the BDM protocol is the largest bottleneck and we are maxed out on the performance. Best way to reduce your total programming time is to take advantage of different commands that we provide that helps speed things up. This includes:
1) Not erasing the entire memory. Instead, use commands like EN (erase if not blank) to quickly check if an erase is even needed. If not, then you can immediately move on to programming. This also removes the need to call Blank Check command if that is also something you are already doing.
2) Make sure you are only programming regions you need to program, and not programming the entire memory.
3) If you are calling the VM command to do any verification at the end, then you should switch to calling VC command to make verification quick and reliable.
Hopefully that helps shave a few seconds off of your programming time.
As you have already done the research, the cyclone will give you great advantage in all other projects you may be working on, especially on ARM devices, to make sure your production programming is speedy and reliable.
Takao
Thanks for your quick response! (and apologies for my delayed one -- we're still mulling over the options)
Like you said, it does appear that the cyclone fx's stand alone programming feature would provide the most reduction to our programming time (with the inclusion of the commands you've mentioned in the cyclone created image). However, our main concern with getting the cylcone fx is the integration of the cyclone fx and NOICE12. It appears we would have two options: 1. to use NOICE12 via the cyclone fx to program our unit or 2. program the unit via cyclone fx's stand alone programming and then using a custom integration workflow/script, quickly pop back into NOICE12 while maintaining NOICE12's debugging functionality. The problem here is that we're trying to work around NOICE12's lack of a native symbols-only mode that would let us load debugging info without reloading
For option 1, my best guess (not having direct access to that equipment) is that while it would most certainly work, it would only be marginally faster than our current process -- my hope is that I'm wrong about this so feel free to correct this point.
For option 2, does the cyclone's control suite have in built capacities that might make this NOICE12 integration smoother to develop and automate? As of now, we have a rudimentary solution (really just a simple python script) that runs before NOICE12's LOAD command but I'm hoping the software suite provided with NOICE12 could significantly improve this.
Lastly, is the PROGZ software included with the cyclone FX's software suite? It seems that if you get cyclone FX, you don't need to get PROGZ -- I'm looking for clarification whether this means that PROGZ's software is included within the provided software suite (as a sort of included program) or, alternatively, that PROGZ's main benefits and optimizations are included within the cyclone FX's own functionality? I ask as we're trying to implement our own custom integration with NOICE12 and the product with the most options would be infinitely preferrable
Greetings,
All PROG software is included with Cyclones, and cyclones don't need licensing to use them. Multilinks will still require them.
Could you tell me what you are trying to do within NOICE so that maybe we can help solve the full problem you are trying to accomplish? Maybe we already have a solution that you did not know about. For example, if you are hopping back into debug to view registers and memory and run calibration, then that can be done within the cyclone as well without having to use other 3rd party software.
Takao
Our main use of NOICE is source level debugging for development and testing. We currently use NOICE to flash and debug our 68HCS12 and use breakpoints (up to 2), monitor and change watch variables and examine memory to view registers, RAM, EEPROM and FLASH. As mentioned before, we experience long wait times when flashing our units and this is not improved when using the Multilink FX universal as opposed to the standard Multilink Universal. We had envisioned using the cyclone to speed up programming and had thought that once the unit is programmed via the cyclone we could just switch back to the NOICE debugger using the multilink (or cyclone if possible).
Greetings,
You are loading up NOICE after each device is programmed? That seem excessive in my opinion. What many of our customers do is create a test application in RAM and load it up after flash programming is done using our UNIT library. You can run, step, breakpoint, read/write registers and RAM space, and read flash memory. This should automate your testing and eliminate NOICE from your production. UNIT12Z would work with your environment.
So instead of improving your flash programming with the different hardware that PEmicro offers, maybe look into automating your testing procedure and that time savings should be worth the investment.
Takao