- NXP Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Home
- :
- 产品论坛
- :
- OSBDM和TBDML
- :
- Re: Combined TBDML/OSBDM Code
Combined TBDML/OSBDM Code
Combined TBDML/OSBDM Code
I use a HCS12 processor board in undergraduate labs. To support programming these we made a number of TBDML programmers. It was reasonably straightforward to extend the use of these to HCS08 through some simple modification of the OSBDM code. Unfortunately, this had the disadvantage of requiring the flash in the programming hardware to be changed when moving between programming HCS12 and HCS08 devices.
There has been some discussion on these forums about combining the OSBDM and TBDML code to produce a single more flexible programmer.
To make this easier I have produced a combined version of the TBDML/OSBDM code. It is also necessary to have a modified windows driver file TBDML.dll so that Codewarrior will talk to the modified BDM which identifies itself as an OSBDM. The OSBDM windows driver file remains unchanged since the software remains compatible with TBDML (at least as far as HCS08 devices).
This code is attached along with brief instructions.
Please let me know if this is useful or if you have other comments - preferably through this discussion board.
Good Luck!
Message Edited by pgo on 2008-02-19 07:10 AM
Message Edited by pgo on 2008-02-19 07:10 AM
A couple of reasons:
The code is compatible with the original OSBDM. While there was an option to use the other endpoints in this code they were optional. In practice they were not used by the DLLs.
The use of BULK endpoints on a low-speed device is not supported by the USB standard. In practice they did work under Windows-XP hence the above option. But worse was to come! Vista is a bit more careful. It checks the descriptors and won't even allow such as device to operate at all!
So - no BULK endpoints!
This option could be used on the JMxx version but I'm not not inclined to try because it break compatibility.
Bye
Message Edited by pgo on 2008-10-07 04:14 AM
When Vpp_en is low Q5 & Q3 are off and have no effect on the circuit. In this case Q2 & Q4 form a symmetrical level shifting circuit between RST_IO and RST_R. This is a pretty standard circuit - refer to the application note cited:
- I2C voltage level conversion - Phillips application note http://www.standardics.nxp.com/support/documents/i2c/pdf/an97055.pdf
To answer your specific question - Initially, the reverse diode in Q2 pulls down the intermediate node (the source). Transistor action in Q2 then aids this.
This circuit is based upon the USBSpyder BDM interface.
Hope this helps!
bye
Dear Josh12,
The previous explanation needs some qualification!
The node labelled Flash12V spends most of its time at 5V. It's only switched to 12V for the RS08. The explanation applies for this case (Q2 and Q4 are almost symmetrical although Q4 may be on for low VDD_BDM values).
When The Flash12V supply is on, but Vpp_en is inactive, then Q4 would be switched on in any case and Q2 acts as a level translator.
When The Flash12V supply is on and Vpp_en is active, then Q4 would be switched off to isolate the programming voltage.
Q3, Q4 and Q5 are only necessary for RS08 programming. Q2 is the only one required for level translation.
bye
Dear All,
Attached is an updated version of the combined TBDML/OSBDM code. It now includes initial support for Condfire V1 devices.
(Second try - previous one had an error!)
bye
Latest version of USBDM software (V1).
Message Edited by pgo on 2008-08-0605:55 AM
Message Edited by pgo on 2008-08-06 05:59 AM
Dear All,
Latest version.
Only significant changes are:
Removing bulk endpoints for Vista Compatibility.
Fixed some bugs with support for Witztronics hardware.
See this post for more information on Vista compatibility:
http://forums.freescale.com/freescale/board/message?board.id=OSBDM08&thread.id=422
bye
Sorry , the last posting was just the Installation files. They did not include the source. This involves some time to repackage them and I haven't done it yet. There are few differences from the earlier more complete posting.
bye
Thanks for all the hard work on this project.
I tried you code change, but the debugger (CW 6.1 for S08) does not recognize the osbdm anymore. It works fine with the current OSBDM firmware.
Any suggestions?
Also, why all the speed changes? You say max crystal is 20Mhz, but it used to be 33Mhz, with JB16.
Thanks,
uCTechnoGeek
I need some more details:
* The firmware is really intended for use with TBDML hardware to allow it to program HCS08s that don't require a VPP voltage. Does your hardware correspond to the schematic provided?
* To use with OSBDM hardware it is necessary to rebuild the firmware. Also you lose the ability to program RS08s (work in progress). Your posting seems to imply you are using OSBDM hardware. Did you rebuild the firmware?
* In any case, the firmware should at least allow the interface to be detected as an OSBDM board provided the USB side of things is the same (pull-up on D-?). Did you program both the ICP code and the USBDM firmware?
The provided firmware works with BDM frequecies to 21 MHz. For most processors the BDM frequency is half the crystal freqency. This may explain the reason for the 33MHz values you have given. I do not believe the original OSBDM firmware would work at at BDM frequency of greater than 19MHz.
Hope this helps
I am using the OSBDM hardware (I don't care about the RS08 support, I'm not a fan of the RS08 anyway).
I did rebuild the firmware and have a pull-up on the D-. Why do you have a pull-down on the D+?
I did not program the ICP code, because I use a 908 programmer and not ICP. Do I still need to have it in the firmware?
Thanks,
uCTechnoGeek
You need the ICP code as it includes the reset vector
! The main code assumes that the ICP code is present in upper part of the flash memory to re-direct the vectors.The pull-down on the D+ is required to allow for reliable differentiation of boot mode for a BLANK chip. Without the pull-down it may boot into the serial debug mode rather than ICP. It is referred to in the application note that describes ICP for the JB16 (AN2399).
bye
Is there any other way to have work your code without using the ICP interface? I mean, download the firmware into JB16 using the MON08 interface. You said in other reply message that it is necessary to use de ICP_boot because your code assumes that the ICP_boot is pressent in the upper part of the flash, so I want to know if is possible to download de ICP_Boot via MON08 to the upper flash and then download the USBDM firmware or if is possible to modify your source code to avoid this problem?
Thank you.
The later version include the ICP code + USBDM code as a single image file. Just program this using the MON08 interface.
This would behave no differently to a more conventional program but is easier to re-program. I see no advantage in removing the ICP code.
Later re-programming using ICP would only replace the USBDM code leaving the ICP code intact.
bye
I already download the last USBDM version into my hardware and the PC can recognize the device. The problem I have now is that I can´t make the codewarrior (for HC(s)08 v6.1) recognize the USBDM, I already copy the DLL file (opensourcebdm.dll) into the codewarrior's gnu folder and rename the original files (OSBDM_S08.dll and OSBDM_RS08) but still not working,
What do you think is happening??
Thank you,
Minush
Dear All,
I've build the board for OSBDM from USBDM_JMxxCLD version. I'm using JM32 and porting code of JM60 as given in the USBDM folder. When I connect it to PC, it detectes USB. Also it pops up the configuration window when I connect it into Codewarrior for debugging.
But, when I try to connect it to the target, it is giving me the "Fatal Error". I've checked in detail and found that there is no activity on RESET pin of the BDM connector.
The target VCC is also OK. BDM pin is low when trying to connect the target.
Plz guide me to resolve this issue.
Thanks and Regards,
Nandulal K. Gavali
Dear Nandulal,
What target are you debugging? For a HCS08 or CFV1 targets it would be possible for there to be no activity on RESET since its use is optional for these targets. For HCS12 it should definitely be in use.
If you think RESET should be doing something then check the signal path from the JM32 through to the reset pin to find out where the reset is going missing. There are a number of things that could affect this such as the FETs being defective/incorrect or wired incorrectly or shorts on the fine wiring.
The BDM pin should be showing activity - not just staying low.
Is the RESET pin high or low?
What version of the firmware/software are you using?
You can try using the debug version of the DLLs and check the log files (either in C:\ or %APPDATA%\usbdm) for more information about what the BDM thinks is happening.
Bye
P.S. Don't double post - It just annoys people!
