Skip to main content
Topic: Brand new OLS (boot)loader tool - Windows and Linux (Read 122412 times) previous topic - next topic

Brand new OLS (boot)loader tool - Windows and Linux

I have just finished this tool - Ols-fwloader. It is mostly intended for linux, but should work with windows and other platforms that do support libusb-1.0.

The source can be downloaded from:
https://github.com/robots/ols-fwloader

I have successfully tested it with my OLS, and it works fine. There is a little problem with first transaction, so don't get confused by the first "Com timeout".

The prerequisites are:
- gcc, and standard devel environment
- libusb-1.0

I have included lame Makefile, that does not use pkg-config, you probably will need to change the paths inside Makefile to make the compilation work.

I am looking for volunteers to  test it. Please just someone who has access to Buspirate, or other means of pic flashing. I have included several measures to protect the bootloader. But there is always a chance it will destroy its self. (The bootloader does not protect its self)

Re: Brand new OLS bootloader tool - Linux

Reply #1
This is a much welcome addition!

There is a big issue with this bootloader because the HID packet is 64 bytes, but the 24J50 has 2 and 64byte write sizes. I went with 2bytes per packet when I ported it. The 2550 (original chip for this bootloader) had 32byte write sizes, so it was much faster. We could speed it up a ton by using the 'flush flag' in the packet to send 2x32 byte packets for 64byte writes instead of 2 bytes per packet. The functionality should already be in the bootloader, I didn't implement it in software because working with the windows driver development kit was a nightmare.
Got a question? Please ask in the forum for the fastest answers.

Re: Brand new OLS bootloader tool - Linux

Reply #2
Quote
The bootloader does not protect its self

I guess I need to refresh myself on the bootloader code.

In this PIC, the flash config words are in the last two words of flash. Since there are two different crystal configurations out there, it is important to protect that region from overwrite. I forget how the bootloader does it. I think it erases by sector and the app doesn't process HEX above the last page, this just a guess, it's been a year since I ported the bootloader.
Got a question? Please ask in the forum for the fastest answers.

Re: Brand new OLS bootloader tool - Linux

Reply #3
On erase the bootloader erases all pages except first two, and last one. But does not protect them from being written to. You can still write stuff to 0.

Re: Brand new OLS bootloader tool - Linux

Reply #4
The larger "page" would help:
Old code:
Code: [Select]
robot@robot ~/devel-DP/ols-fw $ time ./ols-fwloader -V -W -w working.bin 
Bootloader version 0.2.2
Bootloader version 0.2.2
Erasing flash ...
Writing flash ... (0x0800 - 0x4000)
Protecting bootloader - skip @0x3bfe
Checking flash ...
Verified OK! :)

real 0m35.225s
user 0m0.074s
sys 0m0.261s
New code:
Code: [Select]
time ./ols-fwloader -V -W -w working.bin 
Bootloader version 0.2.2
Bootloader version 0.2.2
Erasing flash ...
Writing flash ... (0x0800 - 0x4000)
Protecting bootloader - skip @0x3be0
Checking flash ...
Verify failed :(

real 0m4.019s
user 0m0.001s
sys 0m0.036s

Only problem is the Verify fail. It doesn't seem to write all the data, just some random 2 bytes, skips rest. (random position correct data).
I do understand the bootloader code a bit, but I am not familiar with the way flash is written. I am uploading the changed code to the github. There is OLS_PAGE_SIZE option in the ols-boot.h file. 64 or 2 is valid here, and it selects which code is going to be used.

Re: Brand new OLS bootloader tool - Linux

Reply #5
It seems that it only writes every 64th word, (last two bytes of 128 byte memory piece). And i wonder if it is mine error, or error in bootloader.

Re: Brand new OLS bootloader tool - Linux

Reply #6
probably the bootloader, I only implemented the alternating writes in theory. There might actually be a bit or command you need to send first to get it in 64byte write mode, then you alternate the 'flushflag' bit of the HID packet (see the struct int he old fw-update source) to tell it to first)buffer the packet, and second)write the second packet and save to flash.

I can take a look soon, but maybe not until tomorrow.
Got a question? Please ask in the forum for the fastest answers.

Re: Brand new OLS bootloader tool - Linux

Reply #7
Found a few minutes:

Code: [Select]
;-----------------------------------------------------------------------------
;       write_code
;-----------------------------------------------------------------------------
; DESCR :
; INPUT : boot_cmd
; OUTPUT:
; NOTES : Assume TBLPTRU=0
;-----------------------------------------------------------------------------
write_code
; TBLPTR = addr
rcall load_address_size8 ; TBLPTR=addr cntr=size8 & 0x3C
lfsr FSR0,boot_cmd + CODE_OFFS ; FSR0=&boot_cmd.data
tblrd*- ; TBLPTR--

; while( cntr-- )
write_code_loop
movff POSTINC0, TABLAT
tblwt+* ; *(++Holding_Register) = *data++
; incf hold_r ; hold_r++
; btfsc hold_r, 5 ; if( hold_r == 0x20 )  End of Holding Area
; rcall flash_write ;     write_flash       Dump Holding Area to Flash
decfsz cntr
bra write_code_loop

; tstfsz hold_r ; if( hold_r != 0 )     Holding Area not dumped
; tstfsz boot_cmd + FLUSH_OFFS ; if packet says flush, save to eeprom
btfsc boot_cmd + FLUSH_OFFS, 0 ;if bit 0 is set, write the data
rcall flash_write ;       write_flash     Dump Holding Area to Flash

        return

This is from boot_asm.asm, the actual write function. It is pretty open. It moves cntr bytes from the USB packet to the PIC flash write buffer. I'm not 100% sure where cntr comes from, but I think there is a size variable in the HID packet.

Quote
   btfsc boot_cmd + FLUSH_OFFS, 0   ;if bit 0 is set, write the data
   rcall   flash_write   ;       write_flash     Dump Holding Area to Flash
        return

If BIT 0 of the FLUSH flag is set (is set on every packet for the 2byte writes), then it calls the flash write function. Other wise it waits for next packet.

Code: [Select]
;-----------------------------------------------------------------------------
; Local Functions
;-----------------------------------------------------------------------------
; cntr = boot_rep_size8 = boot_cmd.size8 & 0x3C
load_address_size8
movf boot_cmd + SIZE_OFFS, W
;andlw 0x3C ;!!! 18f24j50
movwf cntr
movwf boot_rep + SIZE_OFFS

; TBLPTR = boot_rep.addr = boot_cmd.addr; hold_r = boot_cmd.addr_lo & 0x1F
load_address
movf boot_cmd + ADDR_HI_OFFS, W
movwf TBLPTRH
movwf boot_rep + ADDR_HI_OFFS
movf boot_cmd + ADDR_LO_OFFS, W
movwf TBLPTRL
movwf boot_rep + ADDR_LO_OFFS
andlw 0x1F
movwf hold_r
return

; write flash (if EECON1.FREE is set will perform block erase)         
flash_write
bcf EECON1, WPROG ; 64byte writes
btfsc boot_cmd + FLUSH_OFFS, 1 ;if bit 1 is set, this is a 2byte write
bsf EECON1, WPROG ; 2byte writes
; write eeprom EEADR,EEDATA must be preset, EEPGD must be cleared      
eeprom_write
; bcf EECON1, CFGS ; Access code memory (not Config)
bsf EECON1, WREN ; Enable write
movlw 0x55
movwf EECON2
movlw 0xAA
movwf EECON2
bsf EECON1, WR ; Start flash/eeprom writing
clrf hold_r ; hold_r=0
return
;-----------------------------------------------------------------------------

The local functions.

Quote
   bcf   EECON1, WPROG   ; 64byte writes
   btfsc boot_cmd + FLUSH_OFFS, 1   ;if bit 1 is set, this is a 2byte write
   bsf   EECON1, WPROG   ; 2byte writes

Flash write sets a 64byte write, but if BIT 1 of the FLUSH byte is set it turns it back to a 2byte write mode. It then activates the write.

I think the load_address functions grab the size and write address from the data packet.

Code: [Select]
;-----------------------------------------------------------------------------
; Constants
;-----------------------------------------------------------------------------
; boot_cmd & boot_rep
CMD_OFFS equ 0
ID_OFFS equ 1
ADDR_LO_OFFS equ 2
ADDR_HI_OFFS equ 3
FLUSH_OFFS equ 4
SIZE_OFFS equ 5
CODE_OFFS equ 6
VER_MAJOR_OFFS equ 2
VER_MINOR_OFFS equ 3
VER_SMINOR_OFFS equ 4
EEDATA_OFFS equ 6

Here is the ASM define of the packet, the C version in the fw-update app is probably clearer. The key is the FLUSH_OFFS bit 0 determines when we write, and FLUSH_OFFS bit 1 sets a 2 or 64 byte write.

None of this is to say that it actually works :)
Got a question? Please ask in the forum for the fastest answers.

Re: Brand new OLS bootloader tool - Linux

Reply #8
I see where the problem is. I have not seen the bit 1 check. I will try the modified loader in few minutes.

Re: Brand new OLS bootloader tool - Linux

Reply #9
The most recent version in git works :-) Flashes OLS in 3.5seconds on my EEEpc. (thats erase write verify).

I have an idea how to implement the same thing in fw_updater. Or I could add windows support to this project.

There are still few things missing - correct error handling for some function calls, integration with ols-loader (so there is just one ultimate tool for ols).

Any suggestions ?

Re: Brand new OLS bootloader tool - Linux

Reply #10
Most of the time, I get confused on which program to use for what part of the firmware. So, I vote for a one-tool-to-rule-them-all! ;)
Good work, keep it up...
when good software is not an alternative...

Re: Brand new OLS bootloader tool - Linux

Reply #11
I'm glad it worked, that's a huge speed increase. Speeds comparable to the 18F version that uses 32/packet writes.

I think windows support on the new utility would be better than continuing to work fw_update, it's a huge beast.
Got a question? Please ask in the forum for the fastest answers.

Re: Brand new OLS bootloader tool - Linux

Reply #12
I am slowly getting there. Next step will be win32 support.

I have created branch in the git repository, with combined tool. Branch name is "ols-combined". This tool can update SPI flash or PIC Application from one place. It does support only one memory at time.

Example: Ols in update mode, entered by button press.
Code: [Select]
./ols-fwloader -f BOOT -n -V -W -w ./working.bin -P /dev/ttyACM0
Found OLS HW: 1, FW: 2.1, Boot: 1
Found flash: ATMEL AT45DB041D
OLS switched to bootloader mode
Bootloader version 0.2.2
Bootloader version 0.2.2
Erasing flash ...
Reading file './working.bin'
Writing flash ... (0x0800 - 0x4000)
Protecting bootloader - skip @0x3be0
Checking flash ...
Verified OK! :)

SPI flash read erase write and verify:
Code: [Select]
./ols-fwloader -f APP -R -W -V -w aasas.bin -r aasas.bin -P /dev/ttyACM0
Found OLS HW: 1, FW: 2.1, Boot: 1
Found flash: ATMEL AT45DB041D
Reading flash
................................................................
Writing file 'aasas.bin'
Erasing flash ...
Chip erase ... done :)
Reading file 'aasas.bin'
Will write 2048 pages
................................................................
Checking flash ...
Verified OK! :)

Some interaction from user is, however, needed. There is no way to exit bootloader to update mode.  It would make complete update process easier.
As before, I have only tested it on prototype OLS and would be glad if someone else could try it !.

Also I have not copied some features like ignore jedec, as it is not appropriate with multiple SPI flash types. If such feature is desired, I will add it. Also any other suggestions are welcome :)

Re: Brand new OLS bootloader tool

Reply #13
I have compiled my new loader for windows. It compiles nicely under CodeBlocks. I have also included CB project in the git.

I have uploaded compiled version here:
http://robot.mysteria.cz/ols-fwloader.exe

What i have not tested is the serial part. As it is kinda annoying to do in vmplayer :( Could someone give it a try ?

Re: Brand new OLS bootloader tool - Windows and Linux

Reply #14
Thanks robots,

I tried it out:
*-n jump: it gives 'device not found' error, ends. OLS IS in update mode though
*update without -n gives the attached verify error
*bitstream update works great

Maybe I used a wrong option for the FW part?
Got a question? Please ask in the forum for the fastest answers.