Tiny Multi Loader for PIC16F15244

[JohnB]

Does anyone have a Hex file for the Tiny Multiloader for the PIC16F15244 and if so could I have a copy?

[JonW]

I have a few, but unfortunately not that one. You can request one from Evan HERE.  I think they are £15

[JohnB]

They are £25 now but I just bought one now.  Set up for RC4 and 5 for USART.

[JonW]

£25!  jeez, pricey

[JohnB]

The first cut didnt work as had the wrong flash size but after second attempt now seems to be OK.

I can offer it free now to any one on forum who has a use for it.

Here's a suggestion, there must be lots of users out there who use Tiny Bootoader Multi and have bootloader code for different processors.  A forum topic on which we could share these bootloaders would be of benifit to all.

[RGV250]

Hi,
It sounds like a good idea but I wonder if this is allowed, did you ask Evan? It seems similar to handing out copies of Positron which we would not like to see.
Also, if it is then i would say it should only be for registered users so they do not just end up everywhere which will probably put the price up for when you have not got the right one.

Regards,
Bob

[JohnB]

Im still having problems with my Bootloader.  Every time I installed the bootloader using PICKit 3 after which I can bootload my program onto the PIC but thereafer, tiny Bootloader cannot find the device.  In this first bootkload I get a warning that the first 4 bytes have been overwritten.

I have been lead to believe previously that you dont need to decalre Bootloader = On infact in other programs I have written which used the bootloader I had specifically declare bootloader = 0.

I have tried declaring bootloader = on and recompiled but the first 4 locations were still overwritten. I have also tried Declaring Bootloader = 0 which worked with Tiny Bootloader on another programm I have been working on.

I dont think the problem is with Evan's bit any more it must be me or the compiler. Can any one help?

[trastikata]

I don't know where the bootloader starts but your code should be offset to avoid that space Declare Compiler_Start_Address = = aaa.

A bootloader that allows to overwrite itself or to overwrite fuse settings that can brick the device doesn't look a sound design.

My bootloaders have simple built in address check and don't allow bricking the device.

[JohnB]

Declare Compiler_Start_Address is only supported on 18F devices.
Do I have to use Org? I've used the Tiny Booloader with an number of devices but never had to do anything specific in my program to accomodate it.

Looking st the hex file with no Bootloader declared the first two words are 0 and the code starts address $0004.

[trastikata]

Declare Compiler_Start_Address is only supported on 18F devices.

I did not know that.

Do I have to use Org? I've used the Tiny Booloader with an number of devices but never had to do anything specific in my program to accomodate it

I don't think ORG will offset the compiler system routines.

[John Lawton]

Does this thread help?

https://protoncompiler.com/index.php/topic,1081.msg8297.html

John

[JohnB]

Not really, Tinybootload does reside at the top of memory but the first 4 bytes are needed to vector to the bootloader on startup. The only way I can think of at the moment is to insert the code at the start of my program which the bootloader expects to see in those locations.

[JonW]

I use the Tiny Bootloader all the time, and didn't need to do anything with the code in Positron for it to work on 16F or 18F devices. I have had trouble with the reset and the timing not seeing the device when using the RTS to start the bootloader on some PCs.

How are you resetting the device to start the bootload?
What is the UART speed, and have you checked that it is correct after bootloading from a timing perspective?

[JohnB]

This is my reset cct.




I use easy PC, this seems to be easiest way to export diagram.
I dont think it's a baudrate problem or reset if I look at the memory it is getting overwritten by the bootloaded code in the first 4 locations.

[top204]

I have created many bootloader firmwares and PC loaders, and even a bootloader on a PIC device, with its own bootloader to update the firmware to bootload to another device (All written in Positron). :-O So they are no stranger to me. :-)

On a 14-bit core device, the PC application reads the hex file and strips off the first 4 code memory (flash memory) words that contain the jump to the main program start, and replaces them with a jump to the bootloader, that resides at the top of flash memory. So everytime a reset occurs, or the device is powered up, the bootloader is called, and after a timeout waiting for something from the PC via serial, it jumps to the main program, whose address was stored in flash, just underneath the bootloader.

So as long as the bootloader is always used, and does not fail as it is re-writing the start vectors, they will stay in place. However, if a device programmer is used, it will erase the jump to the bootloader.

If the bootloader is failing after a single reset, or after a power cycle, then it is not storing flash memory values correctly, so it may have erase and write block sizes incorrect, or the bootloader firmware is not sitting over an erase block correctly.

There is no need for any declares, and they are now for backward compatability only, when the bootloader is sitting at the top of flash memory (the best place for a bootloader).

Regards
Les

[JonW]

Thats a good point Les, John did you check or ammend the ini file in the bootloader as this stores that information on the block sizes

[top204]

In your circuit John, what feeds the base of the transistor?

If it is the device, it will be floating when it resets, and it does not have a pull-down, so it will continuously reset and could screw up the timeout in the bootloader.

Regards
Les

[JohnB]

@top204 It is floating under normal use and connects to RTS when connected to the bootloader.  The PNP transitor does not conduct when the base is floating in this circuit.  I'll see if there is an in file for the TinyMultiBootloader PC program.  I have passed the program back to Evan who tells me he thinks the progam is located 2 bytes out.

[JohnB]

The problem is easily demonstrated in the images below.
Before downloading my file via Tiny Bootloader this is the content of lower memory.

This is the same lower memory after downloading via Tinybootloader.

The first locations which vector to the bootloader are overwritten by the program,

I have some 16F15244 and the bootloader hex available if anyone would care to look into this problem.

[top204]

Send me the files John, via my storypainter email, and I'll take a look at the process on the PIC16F15244 device I still have plugged into the breadboard.

Regards
Les