Historically, PEmicro's PROG has limited the user to specifying one object file at a time to be programmed. But users occasionally encounter situations where they would want to program their bootloader, application, and some additional security settings, all at the same time. Such a configuration was possible using PROG, but quite cumbersome. So PEmicro has implemented a solution that allows programming of multiple object files using a single “PM” and “VM”. This solution is the new “QO” (Queue Object Data) command, which replaces the legacy "SS" command.
Interactive Programmer Implementation (PROG)
Figure 1 shows the old PROG setup (PROGACMP) for programming a single object file. The “SS” (specify object code) command was selected and shown in the “Object File:” text box. Subsequently, the “PM” (program module) and “VM” (verify module) commands would be called to program and verify the single file. This process had to be done each time depending on how many programming files the customer had.
Figure 1. Old PROG Implementation with “SS” Command
A single “QO” command essentially works the same as an “SS” command, however we can call multiple “QO” commands to "queue" files for the same programming operation. When multiple “QO” commands are called, each of the queued object files are later combined into a single data file that is then programmed once into the flash memory of the target device. An example of the “QO” implementation is shown in Figure 2 where all of the user's object files to be programmed at once are specified in the “Queued Program Data Command List”.
Figure 2. New PROG Implementation with multiple “QO” Commands
Command line Programmer Implementation (CPROG)
Much like PROG's interactive solution, our CPROG command-line software has also implemented the “QO” command to simplify programming scripts. This section provides a visual representation of the improved efficiency when using multiple “QO” commands with a single “PM,” versus the multiple “SS” commands with multiple “PM” commands that would have been required in the past.
Figure 3 shows an example of an older configuration script file that would be used to program a bootloader, application and option byte security file into a single target device.
Figure 3. Old CFG script for CPROG with “SS” Command
Notice in the above script the need to specify each object file followed by a separate “PM” and “VM” to program and verify each file. Figure 4 below shows the new approach using the "QO" command to improve efficiency and simplify configuration scripts going forward.
Figure 4. New CFG script for CPROG with “QO” commands
Clear Object Queue Command
The companion command for the new "QO" command is the “CQ” (Clear Object Queue) command. This command can be used at any time to delete all object files that have been specified by previous "QO" commands, and restart the process.
Some Additional Notes
In some scenarios, the “QO” command may not be able to handle programming one or more of the specific files that have been queued. Most often this occurs when attempting to program a file that is not supported in the specified “CM” programming algorithm. Some target devices have both Code Flash and Data Flash regions that wish to be programmed, however, most of our older algorithms do not account for both regions to be included into a single algorithm file. In this case, a single “CM”, “QO”,”PM and “VM” will have to be performed for each region that is not included in the algorithm file. This note should only pertain to certain situations and legacy algorithms, because newer algorithms should have all memory regions supported in one file.
Additionally, some commands such as “CS”, “PS”, “PB”, “PW”, and “SS” have been moved to the “Legacy Command” section within PROG (visible in Figure 2). This is to help with the transition from older software to our new commands. In the future all of these commands will be supported by our queuing data mechanism and will no longer be available to the customer. All legacy configuration scripts with these legacy commands will still work and are compatible with new PROG and CPROG software.
One last note in regard to data overlap detection between multiple object files - by default, PEmicro DOES NOT allow data overlap between object files as it could lead to memory corruption. If in some circumstances overlap is necessary, the only current solution is to use the :IGNOREOVERLAP option within a configuration script and set the parameter to “1”. PEmicro strongly recommends against using this feature if the user is not well-acquainted with what they are attempting.
