Encrypted bootloader.

[ScaleRobotics]

though diolan has the big advantage of being free!). Though, it uses the extended PIC18 instruction set which is not compatible with PBP compiled code... There's probably no chance to make it work as is.

You could do something similar to what these guys did, and turn off the extended instruction bit before you code: http://www.sfcompiler.co.uk/forum/vi...082c05cc975a5a

Maybe an assembly version of run-time config: http://www.picbasic.co.uk/forum/cont...un-Time-Config

Walter

[aberco]

Haha!!! I just found the same solution in another forum as well
Will quote it here:

Some of the newer PIC18s (e.g. 2480, 2580, 4550 etc) support the 'Extended Instruction Set', which enables them to do the offset indexed addressing. However, that's not how mikroC (or any of the MikroE's compilers) has been designed to do. The explanation from Microchip's datasheets for relevant PICs says: When the extended set is disabled, addresses embedded in opcodes are treated as literal memory locations: either as a location in the Access Bank (a = 0), or in a GPR bank designated by the BSR (a = 1). When the extended instruction set is enabled and a = 0, however, a file register argument of 5Fh or less is interpreted as an offset from the pointer value in FSR2 and not as a literal address. For practical purposes, this means that all instructions that use the Access RAM bit as an argument – that is, all byte-oriented and bit-oriented instructions, or almost half of the core PIC18 instructions – may behave differently when the extended instruction set is enabled.

This 'problem' can be solved in two ways:
1. Disable the extended instruction set (e.g. for PIC18F2480, it's in the 4th config word - _CONFIG_4L: _XINST_OFF_4L); it can be done either from the compiler itself (<Project>-><Edit Project>), or in the PICFLASH tool.

2. Leave the extended set enabled, but set the FSR2L and FSR2H to 0's at the beginning of your code; this will make the offset from the location 0x000000, which is the actual address stated. In this case you lose the FSR2 register pair.

I've also seen that config registers can be changed as you said, and thought about disabling extended instructions before running PBP code. It's just a matter of knowing if that can be done within a running program, without messing it up.

First I have to succeed running the bootloader code, and then I'll try these tricks to see if I can get PBP code running smoothly.

Will update progress here, thanks!

[aberco]

I've found a pretty nice tutorial with instructions to set up the diolan bootloader, with extra infos added to diolan's official website (which are pretty straightforward already). There's apparently a bug in EEPROM bootloader triggering with a proposed fix for it.

So far I'm having a hard time running the code. I ported it to 18F4550 by modifying all the references to the 18F4455, and added the missing config bits for the extra code space. All the define for the config (and especially the oscillator) should be ok, as I made a little LED blink program in PBP using the same config and which does work.

The bootloader compiles in MPLAB, I programmed it and inserted by hand the HEX code of my blinking led program at address $0800. The bootloader does behave as expected, after reset, if the loader button is pressed, the LED never blinks which tells that the bootloader is engaged. However it does not shows on the USB peripherials (and I declared existing VID/PID in the config). Bootloader LED never light up too...

Time for more troubleshooting!

[HenrikOlsson]

Guys,
I'm following this with interest and please continue the discussion. However, I was and still am looking for an encrypted serial non USB bootloader so if anyone stumbles across one please let me know!

/Henrik.

[aberco]

Hi Henrik! I would rather work with serial communication too! USB is clean and easy on the user side of things but it is far more challenging for us programmers. Maybe diolan's encryption routine can be reused within a serial bootloader, but that mean coding in ASM. The good side of things is that the code for encrypting the HEX code for the target is available, and communication protocol would still be handled by the original serial loader.

Well, it seems that I have no luck with USB on my little 18F4550 development board. Since I switched to 13/14K50 I have not managed to get anything running again on the 4550. I think that I managed to implement correctly the bootloader, but the USB interface is completely unresponsive. This is also true with a couple of other test programs (DT_HID260, HID demo, CDC demo). The configuration seems to be fine though, it run at the correct speed and USB module should be clocked at 48Mhz...

Maybe I'll concentrate my next efforts on porting the bootloader to 13/14K50, which is the MCU I really need for my projects (and I have USB working with it!).