MS-II
Posted: Tue Nov 30, 2004 8:25 am
Below I've pasted an update from Bruce Bowling on the MS-II release. FYI for anyone interested...
==================================================
Update, Oct 9,2004 on MS-II progress:
A) Al is working on the last board revision, which are a few cleanup issues and a few additions:
- Make the stepper Motor driver chip enable pin be under the control of the processor and not hard-wired.
- Bring out some of the unused pins on the C32 processor out on the 40-pin DIP socket.
- Add a output signal for knock windowing control.
- Move the bootloader switch off the board and use the same I/O signal as is used in the original MS (the ADC channel used for monitoring battery voltage). The idea is to have one bootloader switch location. However, since then I have been implementing the Serial Monitor/bootloader code on the device (see below) and I may have Al leave the switch where it is.
- Get one very small prototype board runs made to verify operation once again.
B) Al has the embedded Codewarrior software frozen at V0.9 - it is at a point where it needs testing on operating engines.
C) My task as of late was to implement the bootloader function in the 9S12C32 processor. I am aware of the inherent problems with the existing bootloader in the MS's GP32, where one has to try many different things in order to get it to actually work. The thing about a bootloader is that you get one shot at it, since they are (usually) implemented as protected code in memory so that it will not get erased. The GP32's version left some things to be desired.
Not this time around. I have implemented the Serial Monitor function as outlined in appnote AN2548:
http://www.freescale.com/files/microcon ... AN2548.pdf
This is turning out to be a godsend! Not only does it allow one to upload/download data to/from memory, it allows one to actually debug thru the serial interface. What this means is that one does not have to purchase a BDM cable, they simply plug in the serial cable and off they go. And - Codewarrior has this mode seamlessly implemented, so if one picks the serial monitor mode in CW, the tool connects using the serial port, downloads the code into flash, and allows pretty much all debug capabilities (step/watch/breakpoint/etc). Its pretty slick, and appears to be extremely robust. It sets the serial port at 115,200 baud and the processor core clock frequency to 24 MHz - it can upload 20K of flash code and burn it in under 3 seconds!
The only hiccup is that Al runs his code at 16 MHz and sets the serial port at 9600 baud, so when Al's code sets up the SCI port communications is lost under debug. This does not affect the serial bootloader function, only the debugging, so it is not a major issue, since the vast majority of people will just be using this to upload code and not for detailed code development. But, all I need to do is convince Al to jack up the clock frequency from 16 to 24 MHz and use a 115.2Kbaud serial rate and we are go to go (:twisted
A couple of things: first, now that we have a bootloader function, we need a front-end program running on the PC which serves up the .s19 record file in binary mode. The serial monitor program uses a binary command set - it does not do the s-record parsing, this is left to the PC side to implement. So, no firing up hyperterminal and sending a text file of .s19 format, this is a little more sophisticated. What is needed is a very simple app which reads in the .s19 file and converts this to the required binary command set in order to flash the device. The appnote above outlines what is required. If someone wants to implement this let me know, otherwise it is on my to-do list. Also, rumor has it that such a program exists for free on the Technological Arts site (they use the exact same serial monitor), but I have not checked it out yet. Also, if someone does write this code, I can give them a command dump from Metrowerks showing every command sent over to the serial monitor to load the entire MS-II application, so that they can get a feel for what is really going on.
Second, an idea I have been kicking around. Al's code is getting pretty much complete for pass one. The issue is that it is nearly 20K of flash space (everything, including tables) and this requires an extended Codewarrior license to compile everything (the free license is limited to 12K code generation). But, we now have this nifty bootloader/debugger which can burn flash anywhere (which takes up 2K). So, we have 10K of space left over in a nice block(s) of memory. So, in theory, Al could put in strategic places in his main MS-II code (like several places in the main loop) a simple jsr call to somewhere in this 10K block. Now, the default in this block (uploaded when the main MS-II code is burned) would be to simply do a return - it does nothing. But, a savvy code person could intercept this call and actually put in their own code at this jump location - think of these as "stubs" where one can upload their own code patches in their own flash "playground", independent of the main MS-II code. For instance, right before the MS-II code sets the injector pulsewidths, the main loop code could do a jsr branch to the flash block, and the default would be to simply return. Some could place their own code there and modify/add their own stuff. If they include the same definition of variables as are used in the main code, then this stub code could have access to all variables. The nice thing about this is that one can leave the main MS-II code in place and add their own overriding code if they want to, in their own place. And, they would have enough code generation capability with the freeware version of Codewarrior. Something to think about...
Finally, another indicator that the HCS12 family was the correct processor choice for MS-II - see the new MC9S12NE64:
http://www.freescale.com/webapp/sps/sit ... 468636K100
This is a HCS12 device with a 10/100 ethernet MAC *and* PHY on one chip. All you have to do is provide magnetics and a RJ-45 and you have ethernet connectivity at $9.00. And, there is a freeware port of TCP/IP which is ported to Codewarrior. I have been playing with an eval board with the free TCP/IP stack and this part is indeed sweet. The UDP packet function alone (with DHCP) is enough to implement a nice high-speed communications function for MS. Now that the MS code is ported to the HCS12, changing over the SCI serial data to Ethernet UDP would be possible without a lot of work. This is just FYI....
==================================================
Update, Oct 9,2004 on MS-II progress:
A) Al is working on the last board revision, which are a few cleanup issues and a few additions:
- Make the stepper Motor driver chip enable pin be under the control of the processor and not hard-wired.
- Bring out some of the unused pins on the C32 processor out on the 40-pin DIP socket.
- Add a output signal for knock windowing control.
- Move the bootloader switch off the board and use the same I/O signal as is used in the original MS (the ADC channel used for monitoring battery voltage). The idea is to have one bootloader switch location. However, since then I have been implementing the Serial Monitor/bootloader code on the device (see below) and I may have Al leave the switch where it is.
- Get one very small prototype board runs made to verify operation once again.
B) Al has the embedded Codewarrior software frozen at V0.9 - it is at a point where it needs testing on operating engines.
C) My task as of late was to implement the bootloader function in the 9S12C32 processor. I am aware of the inherent problems with the existing bootloader in the MS's GP32, where one has to try many different things in order to get it to actually work. The thing about a bootloader is that you get one shot at it, since they are (usually) implemented as protected code in memory so that it will not get erased. The GP32's version left some things to be desired.
Not this time around. I have implemented the Serial Monitor function as outlined in appnote AN2548:
http://www.freescale.com/files/microcon ... AN2548.pdf
This is turning out to be a godsend! Not only does it allow one to upload/download data to/from memory, it allows one to actually debug thru the serial interface. What this means is that one does not have to purchase a BDM cable, they simply plug in the serial cable and off they go. And - Codewarrior has this mode seamlessly implemented, so if one picks the serial monitor mode in CW, the tool connects using the serial port, downloads the code into flash, and allows pretty much all debug capabilities (step/watch/breakpoint/etc). Its pretty slick, and appears to be extremely robust. It sets the serial port at 115,200 baud and the processor core clock frequency to 24 MHz - it can upload 20K of flash code and burn it in under 3 seconds!
The only hiccup is that Al runs his code at 16 MHz and sets the serial port at 9600 baud, so when Al's code sets up the SCI port communications is lost under debug. This does not affect the serial bootloader function, only the debugging, so it is not a major issue, since the vast majority of people will just be using this to upload code and not for detailed code development. But, all I need to do is convince Al to jack up the clock frequency from 16 to 24 MHz and use a 115.2Kbaud serial rate and we are go to go (:twisted
A couple of things: first, now that we have a bootloader function, we need a front-end program running on the PC which serves up the .s19 record file in binary mode. The serial monitor program uses a binary command set - it does not do the s-record parsing, this is left to the PC side to implement. So, no firing up hyperterminal and sending a text file of .s19 format, this is a little more sophisticated. What is needed is a very simple app which reads in the .s19 file and converts this to the required binary command set in order to flash the device. The appnote above outlines what is required. If someone wants to implement this let me know, otherwise it is on my to-do list. Also, rumor has it that such a program exists for free on the Technological Arts site (they use the exact same serial monitor), but I have not checked it out yet. Also, if someone does write this code, I can give them a command dump from Metrowerks showing every command sent over to the serial monitor to load the entire MS-II application, so that they can get a feel for what is really going on.
Second, an idea I have been kicking around. Al's code is getting pretty much complete for pass one. The issue is that it is nearly 20K of flash space (everything, including tables) and this requires an extended Codewarrior license to compile everything (the free license is limited to 12K code generation). But, we now have this nifty bootloader/debugger which can burn flash anywhere (which takes up 2K). So, we have 10K of space left over in a nice block(s) of memory. So, in theory, Al could put in strategic places in his main MS-II code (like several places in the main loop) a simple jsr call to somewhere in this 10K block. Now, the default in this block (uploaded when the main MS-II code is burned) would be to simply do a return - it does nothing. But, a savvy code person could intercept this call and actually put in their own code at this jump location - think of these as "stubs" where one can upload their own code patches in their own flash "playground", independent of the main MS-II code. For instance, right before the MS-II code sets the injector pulsewidths, the main loop code could do a jsr branch to the flash block, and the default would be to simply return. Some could place their own code there and modify/add their own stuff. If they include the same definition of variables as are used in the main code, then this stub code could have access to all variables. The nice thing about this is that one can leave the main MS-II code in place and add their own overriding code if they want to, in their own place. And, they would have enough code generation capability with the freeware version of Codewarrior. Something to think about...
Finally, another indicator that the HCS12 family was the correct processor choice for MS-II - see the new MC9S12NE64:
http://www.freescale.com/webapp/sps/sit ... 468636K100
This is a HCS12 device with a 10/100 ethernet MAC *and* PHY on one chip. All you have to do is provide magnetics and a RJ-45 and you have ethernet connectivity at $9.00. And, there is a freeware port of TCP/IP which is ported to Codewarrior. I have been playing with an eval board with the free TCP/IP stack and this part is indeed sweet. The UDP packet function alone (with DHCP) is enough to implement a nice high-speed communications function for MS. Now that the MS code is ported to the HCS12, changing over the SCI serial data to Ethernet UDP would be possible without a lot of work. This is just FYI....
