解決済! 解決策の投稿を見る。
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
Hi Stipey,
Stipey75 wrote:My question is...it's possible to generate a single s19 file to flash AC32 with bootloader and user app together?
When you link your application, you can have the bootloader added to the application's S19 file. Just put a reference to the bootloader's S19 file in the application's PRM file with the HEXFILE command. Like so:
HEXFILE ..\DSPv3\Core1.s19
rocco wrote:Hi Stipey,
Stipey75 wrote:My question is...it's possible to generate a single s19 file to flash AC32 with bootloader and user app together?
When you link your application, you can have the bootloader added to the application's S19 file. Just put a reference to the bootloader's S19 file in the application's PRM file with the HEXFILE command. Like so:
HEXFILE ..\DSPv3\Core1.s19
Hi, just need to warn that doing this will only concatenate the two existing S19 files together (the one being compiled + one external - here Core1). But if you do this with AN2295 Bootloader, this won't work.
One important requirement of AN2295 bootloader was that user does not need to modify his code in any way (except for smaller memory and NVOPT, NVPROT features - see AN2295 document). The major thing is that user's S19 interrupt vectors are 'delivered' into bootloader without any change and the PC application (hc08sprg.exe) manages its translation (or redirection) to the right place. In case of HC08 (and very few S08), vector are translated into jumptable, majority of S08 just relocate to another location. This is done on-fly thus simple concatenation won't work here. The converter tool that I've mentioned above actually does this.
Regards, Pavel
Hi Pavel,
I did not realize that your bootloader was that sophisticated.
Since my bootloader does not relocate the vector table, concatenation works.
Hi, there is no automated utility available to make the S19 conversion and concatenation (actually we had some for HC08 but it is yet internal and not applicable to S08 way of handling vectors).
Fortunately there's simple manual way of doing the same:
- 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}
Assuming your Application does not modify the Flash e.g. after startup, there you get the binary image with both Application and Bootloader.
Pavel
Thanks a lot! It's really a good solution quick and easy!
Just a couple of doubts...i am new to freescale so tell me if i'm right...
Download bootloader with BDM --> OK!
Download user app with SCI --> OK!
Connect BDM --> frist question, when i connect it erases with the debugger tool all memory so i lose or the bootloade or the app...but i think i have to check the option to protect a memory zone, correct?
Read the memory --> How can i save the entire memory? I have to use a command??
thanks a lot...
Stipey75 wrote:
...Connect BDM --> frist question, when i connect it erases with the debugger tool all memory so i lose or the bootloade or the app...but i think i have to check the option to protect a memory zone, correct?
Read the memory --> How can i save the entire memory? I have to use a command??
Hi, it is not clear which BDM pod are you using. At least P&E Micro Multilink dialogue gives two options, latter called "Hotsync" which allows just to connect to the target without erasing. Unfortunately I'm not familiar with other BDM pods.
Once you're through, in Command window you can issue command: SAVE <range> <filename> [<offset>] [;A]
and save your Flash range into file.
Pavel
Exactly what i need!! Thanks a lot works nicely!!
Hi all,
I'm facing some issues trying to boot via half duplex SCI for MCF51AC128
Using AN2295 and a focused software, directly received from Freescale, I'm not able to get a communication between the microcontroller and the Pc
1) I have transferred V1AC256-SCI-BootLoader-2-CW62.zip in my own project (**)
2) I have compiled and programmed my board, which has a single wire interface to the Pc
3) I have suppressed the echo from the MCU
4) Launched the bootloader on the Pc, which waits the 0xFC character
5) Mcu sends 0xFC a 115200 bps to the Pc
6) Pc replies with 0xFC
7) Mcu sends again 0xFC
8) Pc sends 0x49 (Ident)
9) Mcu replies with string "\n\rMCF51AC256A\n\r"
10) Pc doesn't recognize the protocol and the flow get stucked (I think the Pc should receive the infos stated in AN2295, pag.10),but I do not find these informations in the firmwware V1AC256-SCI-BootLoader-2-CW62.zip (**)
Anybody can help, please!?!
Regards,
Paolo
Seems like you've mixed up AN2295-based bootloader with another one. For 51AC-family you need to use files from this package: http://www.freescale.com/files/community_files/8BITCOMM/hc08sprg-update-9.2.1.exe.zip
Pavel
Hi Pavel, thanks for your quick reply
I used the new GUI, chosing the relative communication port where the single wire link is mapped (on my Pc is Com8, instead of the default Com1) and I did not observe any communication during bootloading
I checked it again and found the port was switched back to Com1
How can I mantain the correct communication port!?!
Regards,
Paolo
Hello everybody,
I'm working with the LG32 and it will be perfect for me to have a serial bootloader like an2295 working. Is it easy to reuse some code from any microcontroller of AN2295 and obtain a bootloader for LL32?
Thanks,
Hope this file helps. If you have your files modified for LG, I would appreciate sharing these. They can become a part of 'official' release.
Pavel
Thanks Pavel for your quick reply!
I talked this morning with my boss and he said that we could use for our project the LL16 because has a better price than LC and LH options, the alpha version ( hc08sprg-LHLL-alpha-2.exe.zip 262 KB) is only for LH, ¿are there something for LL16 or it's under development?
Thanks again!
Ooooops, I should have mentioned that LL and LH should be (bootloader-wise) identical, possibly also LG (automotive variant). That's why the alpha files are named LHLL. LL8 and LL16 options are not yet in there but you can quickly modify the reported memory areas to something like:
DEFAULT_ROM: SECTION ID_STRING: IF SIZE = 8 DC.B 1 ; number of Flash blocks ADDR24 $00D800 ; START ADDRESS OF FLASH #1 ADDR24 REL_VECT ; END ADDRESS OF FLASH #1 ENDIF IF SIZE = 16 DC.B 1 ; number of Flash blocks ADDR24 $00C000 ; START ADDRESS OF FLASH #1 ADDR24 REL_VECT ; END ADDRESS OF FLASH #1 ENDIF IF SIZE = 36 ......
... and of coure to modify external define SIZE to 8 or 16 (in the Assembler setting tab). I will later modify this target for these values. Would be great if you test it now as I do not have LL silicon anywhere near me.
Alternatively you can use LH64 bootloader as it is and load LL16 code normally. If you don't go outside LL16's real Flash you should be OK.
Pavel
I put your code on a new project for LL16(AN2295SWLH and the last message in this forum), changed the compiler options to target LL16 and downloaded the program to the DEMO09S08LL16, but when I use the GUI or hc08sprog.exe appears the message that I attach in this reply.
Oriol
patash wrote:I put your code on a new project for LL16(AN2295SWLH and the last message in this forum), changed the compiler options to target LL16 and downloaded the program to the DEMO09S08LL16, but when I use the GUI or hc08sprog.exe appears the message that I attach in this reply.
Oriol
The latest hc08sprg.exe attached below may help.
Pavel
P.S. run hc08sprg.exe /? to see the list of supported SDIDs.
Hello again,
When I try to program the LL16 throws new error codes, I think that the bootloader is closer to work (I attached new pdf)
Thanks again Pavel,
Oriol
patash wrote:Hello again,
When I try to program the LL16 throws new error codes, I think that the bootloader is closer to work (I attached new pdf)
Thanks again Pavel,
Oriol
Umm, LL8/16 does not need longer addressing. Find attached version modified for LL8/16. This simplified version also depends on the right ICS trim value stored in Flash (@ 0xFFAF). P&E Micro tool chain does that for you.
Let me know, whether it works so I can include it into the next release.
Pavel
Pavel, works fine your bootloader with the LL16!! I uploaded a new firmware to my DEMO9S08LL16. only one thing, the program works well but throws a warning when programming (I attach a screen capture).
Thanks a lot!!!
patash wrote:Pavel, works fine your bootloader with the LL16!! I uploaded a new firmware to my DEMO9S08LL16. only one thing, the program works well but throws a warning when programming (I attach a screen capture).
Thanks a lot!!!
Not a bug, this is a feature. The tool reports that your code contains some data @ FFBD - which is NVPROT location. This one is actually covered (used) by the bootloader and cannot be altered. AN2295 mentions this as one (of few) differences of behaviour with vs. without bootloader.
Regarding protection - there's one feature that may not be well known - majority of S08 devices can write into FPROT register from run-time and can change the value of this register toward lower values (i.e. toward lower addresses). The lowered protected address then remains active till the next device reset. See the datasheet for details.
Pavel
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!!