The power on the BDM header usually powers the level converted, target side, BDM connection circuitry of the adapter. Even though the bulk of the adapter is powered by the USB or whatever.
Message Edited by peg on 03-29-200606:53 AM
I have been following your troubles both here and at P&E but I haven't been able to assist because I have got a P&E USB Multilink and the **bleep** thing just works so I haven't learned a lot about it.
I have also been looking into making the open source BDM so I know the circuit there. The P&E handles different target voltages and has a LED that only comes on when target power is present so I presume it is similar.
I have only used my USB-ML-12 to talk to GB/GT devices. I will be talking to QG's if Freescale ever get around to sending me some.
P.S. Don't ever try to discuss sock repair here or you will get bleeped!!!
Message Edited by peg on 03-29-200609:28 AM
I have attached with this message the Codewarrior examples that are referenced in the quick start guide.
Message Edited by Boost on 04-19-200612:28 PM
Still chasing some matrix keypad info, huh.
I use one based on the example in M68HC05AG/AD Rev. 1, don't know if its still here as I have one made from a tree.
Its part of the full application which is a home thermostat. Doesn't use KBI but may help you to get started with some basic concepts (Oh dear there is that word again).
Message Edited by airswit on 05-13-200602:17 PM
airswit wrote:wow, that is actually pretty easy to accomplish. however, is there perhaps a way to do it so that the whole process doesn't take 100ms, or so?p.s. thanks for the link, peg!
As I said the link is the top shelf of my bookcase, but I found this on the C8A page:
I did not wait for it to download though.
The delays aren't a problem in my application although I am using 15ms which was discovered to work OK accidently. A calculation mistake to change the sample code to suit my bus freq. gave this and it was not discovered until many years later when I changed the product from 05C8A to 08GP32 with a new bus freq. that required the delay to be recalculated. So I just kept the wrong delay. I am using good quality Rafi keyswitches though.
Message Edited by peg on 05-16-200608:25 AM
I bought a DEMO9S08QG8 kit.
I wonder If I can used the BDM_PORT to program other king of MCU?
Like the QG4 or might be other kind of core family?
Hello and welcome to the fora, GrungeRey.
Yes you can do this as long as you avoid the latest versions of Codewarrior that specifically disable this ability.
Refer to this post to see how to modify new versions to allow this.
I'm new to this forum and hope I,m on the correct one, if not please direct me.
My comp is running'XP' and I'm using CW.V5 special edition, not registered, single user.
I have previously used the GT16 chip many times and programmed over 10K in assembler
without problem. Now I am trying to use the DemoQG8 board with the USB interface.
Big problems, I can program up to 1K (a previous project) with no problems, the current project 3.4K assembly (not yet complete)
but ready for some run tests is perfectly o/k in FCS mode, switching to PE Multilink, comms = O/K, program flash?
YES, goes through all the motions and returns flash programmed and verified! Program window closes, debug opens,
source,data,procedure, windows are empty, the memory window shows all Zero from E000 (reset entry) The assembly window (reset to zero) has no relevance to the source code. I can open the source code window which is correct, but I understand this is a read only file. I'm pretty sure the chip is blank.
Question, why can I program a 16k GT16 using a (homebuilt) mono8 interface with as much code as I like and yet not a QG8 (3.5K assembly) with the demoQG8 board?
Do I need to register the product CW.V5 This was downloaded from the WWW a couple of years ago and so I have no registration key anyway.
Or am I simply missing somethig in the settings panel?
I will be most grateful for any help.
My Apologies to you all,
After studying the .map and the .prm files I found the problem (7 days later)!
I obviously write code from the reset entry point but place text files used for the LCD etc at the top of memory,
Out of the way of any code. I had missed the fact that the flash programming registers where up there preceding the vectors!
I had overwritten the flash registers with my own text code. What an idiot.
After moving the text files down by 32 bytes all now works well, I can program and debug the chip.
To Peg if your watching, I am using your suggested BDM link from the DemoQG8 board to my target board (another forum)
BDM compatibility I seem to recall.
It works well and I am able to Debug and track the real application, thanks for the advise.
Again my apologies to you all for wasting your time due to my own stupidity.
Best wishes and thanks,
If you use the standard, CW supplied include file for the specific device, the value of ROMEnd is defined, in this case:
ROMEnd: equ $0000FFAD
The file derivative.inc, which is automatically created by the CW new project wizard, does include the appropriate file.
You might then use the following method, which should apply for any HCS08 device you happen to use:
LCD_DATASIZE equ xxxx
ORG ROMEnd - LCD_DATASIZE
dc.b "LCD text start",0
Writing inappropriate value to some of the non-volatile registers might cause your program to malfunction. However, I cannot see the mechanism by which the flash programming would not be completed. Programming the NV registers is part of the normal programming procedure.
Thanks for your response and the code tips (now in use). Makes much better sense than my own.
[ Text: Equ xxxx ] Followed by 24 messages, then figure out how much memory I need!
I have again looked at the N.V register summary, I was overwriting FFAO through FFDO.
FFCO through FFCF = rom_1, it was not defined, so that may have caused a problem? I think
the problem was overwriting FFAE through FFBF, the N.V registers, More than likely I had changed the
trim bits and the flash security bits? But this would seem to indicate that the N.V registers where programmed
first? Resulting in my case, in a blank chip, although the Multilink programming routine indicated " flash erased, programmed and verified, ready for debug" but the chip was blank! Perhaps a bug in cw-v5? or more likely my own lack of understanding.
I don't know, I can only say that since I moved the text code down to a new Equ the problem is solved.
Thanks again for your help Mac,
Really nice datum it is!
Thanks for sharing!
Retrieving data ...