已解决! 转到解答。
Hi Pavel and thanks for your response!
It worked like a charm!
I changed that line and stopt feeding my watchdog when I wanted to reboot and enter the bootloader.
Since I spent alot of time searching for a solution like this on the forum and did not find it, mabey this should be documented in someway :smileyhappy:
Best regards
Martin
Stipey75 wrote:Hi everybody!
Just another question..i am spending sometime to flash my device with bootloader and everything works fine!
I'm having only problems if i try to use a USB-RS232 adapter i'don' receive any ack. Is there any difference with USB adapter?
Is it normal or i am missing something??
Thanks!!
Hi,
the USB<>RS232 converters generally do work fine. As long as Windows sees standard COM port (or Linux ACM/CDC device), the bootloader typically works OK. You haven't mentioned the type of the device - both well-know FTDI and Prolific chips are tested and perfectly functional. I would suspect the hardware issues possibly. You might try to use Debug version of hc08sprg.exe to see what data are being transferred on the RS232 layer.
Pavel
Solved!
It was my fault on the command line of the exe program. I used wrong parameter for port..for COM2 i wrote 2 instead of COM2 so i was able to flash only wtih default COM number 1!
Thanks anyway!
Hello, another question regardinng the creation of a single s19 file with bootloader and app together.
I used the procedure suggested in the previous post:
- use BDM pod to program Bootloader code itself
- use Bootlooader to load Application code via SCI
- connect BDM pod again and read all Flash content into a S19 file
- {if necessary remove the lines with empty Flash = containing FF bytes only}
And worked really good.
Now i'd like to secure Flash with FOPT secure bits to make flash unreadable to other people. If I use these bits in the bootloader file i suppose that i can use bootloader code to flash my app in memory, but it's possible to generate a single file with bootloader and app together?
I think that i can't realize the third point:
- connect BDM pod again and read all Flash content into a S19 file
because memory is secured so it will be cleaned when i try to use hotsync with bdm. It's correct?
I'am just makin suppositions because now i have no hw with me. I'll try tomorrow in office.
Thanks!!
Correct, once you secure Flash, you can't read it anymore.
You can trick this easily
- don't secure it at all
- do all steps as required
- finally insert the line below into your resulting S19 (somewhere between S0 header and S9 footer):
S104FFBF40FD
This will include 0x40 value onto 0xFFBF location which should add security.
S-record are easy to ready and easy to handle.
S1 header (16-bit address)
04 length of data to follow
FFBF address
40 data
FD checksum of all data starting at the length position (04+FF+BF+40+FD=2FF --> modulo 0x100 is 0xFF - correct csum).
Pavel
Hi!
Thanks for the reply..i'm happy because i made a similar solution..
I edited the line in s19 file where there was the security setting and changed it manually as you said (recalculating the checksum also). It worked really good.
By the way...with my final s19 complete (bootload+app) i had another problem...on one hw it worked perfect on antoher hw of the same product i have problems with SCI..i found it was trim value! Trim value is set at 0xFFBE by bdm when i flash the bootloader...the i program with sci the app and extract the complete file.
The problem is that this s19 complete file has a trim value set for that hw inside and when i use the load application option in hi wave bdm calculate trim value but doesn't write it because it's not blank! I made the same trick...put 0xFF to the location 0xFFBE in s19 file and so it works because the TRIM value is blank during flashing app process...is it good for you?
Thanks
Hi Guys,
Could anyone willing to share their DLL/DLL wrapper for the bootloader or the Bootloader GUI source code? I have a Visual Basic app that has Serial communication and would it be possible to embbed the hc08sprg.exe inside the visual basic app and make it as if it's one executable file ?
Thanks,
Designer11 wrote:Hi Guys,
Could anyone willing to share their DLL/DLL wrapper for the bootloader or the Bootloader GUI source code? I have a Visual Basic app that has Serial communication and would it be possible to embbed the hc08sprg.exe inside the visual basic app and make it as if it's one executable file ?
Thanks,
Negative. We do not share the source code for Bootloader GUI. Actually, this GUI does only a very simple thing: it runs hc08sprg.exe in a separate process and adds the right COM port number, speed and S19 filename. I guess you've seen the black "command" window executing hc08sprg.exe.
I believe you can do the same in VB.
Pavel
Hi,
MCF51AC series is already supported via 9.2.1 update mentioned few pages back (http://www.freescale.com/files/community_files/8BITCOMM/hc08sprg-update-9.2.1.exe.zip) - just load it, use it and let me eventually know if you are successful.
I'm way too late in pushing for official release 10 that should cover all intermediate updates done via this forum.
Pavel
Hi.
I have a MC9S08AC48 micro.
I would upload program with bootloader.
I want use all vector interrupt vectors of micro, from 0xFFC0 to 0xFFFF (default of bootloader is 0xFFCC to 0xFFFF).
I tried to transfer ROM zone from prm file but I don't be able to upload final program.
any suggests?
thanks in advance.
...I have a MC9S08AC48 micro.
I would upload program with bootloader.
I want use all vector interrupt vectors of micro, from 0xFFC0 to 0xFFFF (default of bootloader is 0xFFCC to 0xFFFF).
Hallo, not sure if I really understand what you mean be "use all vectors ... from 0xFFC0 to..."
Original code defines the "interrupt vector area" by its beginning using this macro:
INT_VECT EQU $FFC6 ; start of table of original vectors
the end is (by design) at 0xFFFE:0xFFFF = reset vector.
Anything between these two addresses is considered as interrupt vectors and is treated specifically. Looking into the manual - any S19 records (of the user code) is taken away and is redirected (relocated) into the following area:
REL_VECT EQU $FDC6 ; newly relocated int. vectors
There are in fact two flavours of S08 devices. The majority do support automatic relocation of interrupt vectors - to the first unprotected Flash page. The AN2295 bootloader supports (and uses) this feature - AN2295 master simply moves all vectors from above mentioned area and moves them here. S08AC/AW devices are like that. {Some others do not support this feature and are using redirected jumps to the memory, adding one more JMP instruction into each interrupt, just like HC08 devices}.
If I understand your question correctly - you simply need to modify these two macros to 0xFFC0 (and 0xFDC0 respectively) and you should be able to use "all interrupt vectors". Not sure why do you need this since there are no physical peripherals that would use these vectors. I am missing something here.
If you'd describe your need little more closer, I could possibly add some more advice here.
Pavel
Hi,
I am trying to use this bootloader with S08JM60 by virtual com, but when I try put simple s19 with command: hc08spg.exe COM10 9600 1led.s19 it gives me warning "memory not fit" and doesn't work.
listing:
"Parsed S-record lines: 44 Bytes total: 1197
Source address range: 0x1960-0xFFFF
Waiting for MCU reset ACK...received 0xfc (good).
Bootloader protocol version: 0x02 (S08, read command supported)
Bootloader version string:
System device ID: 0x016 [MC9S08JM(16-60)] rev. 1
Number of memory blocks: 2
Memory block #1: 0x10B0-0x17FE
Memory block #2: 0x1960-0xE5BF
Erase block size: 512 bytes
Write block size: 64 bytes
Original vector table: 0xFFC0-0xFFFF
New vector table: 0xE5C0-0xE5FF
WARNING! S19 image will not fit into available memory (at address 0xFABC)!
Are you sure to program part? [y/N]: y
Memory reading: R 0xFABC 20%
Verification failed at address 0xFABC, image: [0x9D], MCU: [0x9E]
Program memory failed.
"
Do you know why is that happened , what is the reason ?
Thank you for response.
Regards,
Piotr
tranq wrote:
...
Number of memory blocks: 2
Memory block #1: 0x10B0-0x17FE
Memory block #2: 0x1960-0xE5BF...
WARNING! S19 image will not fit into available memory (at address 0xFABC)!
...
Memory reading: R 0xFABC 20%
Verification failed at address 0xFABC, image: [0x9D], MCU: [0x9E]
Program memory failed.
Hi, the reason is quite simple - your user code S19 contains some record at 0xFABC memory location that obviously collides with flash memory allocation of the bootloader.
It seems that you are using USB version of JM60 bootloader in which the memory locations between 0xE5C0 and 0xFFFF are used by the bootloader itself. Nothing (except your code interrupt vectors) can be placed here.
The suggestion is to (re)move the items that are using 0xFABC address, either by looking in your prm file and/or variables allocated at fixes address using @<address> modificator.
Pavel