Mecanique's internal bootloader OSC

MC Studio bootloader works great with xtal. But, there is always a but, when I load 18F4620_04.hex using meProg U2 with INTRC(INTIO2) configured then MC bootloader no longer functions, because (I think) there is no way (with my skill set) to set the bootloader speed at 1 MHz or set the target at 4 MHz with OSCCON.

This important because we want to simplify hardware in the field at scale and not use external crystals, allow code upgrades, and watch/modify data flow using a notebook serial port. It must be dirt cheap. The solar tracking code will be open source for places like India and China, posted in user-friendly BASIC. They hopefully will only need PBP + MC Studio Plus for local integration.

I saw in the forum a patch for 16F****. Is there something for 18F4620 using internal oscillators, perhaps working with PIC internal OSCCON default 1 MHz, or a method to smuggle in a 4 MHZ OSCCON ?

_OSC_INTIO67_1H

If I understand what you are trying to do correctly:

You can program the bootloader with a default oscillator (say 4MHz) and then - in your code, set the running frequency to 1Mhz. So yes, you can use the 4MHz version of the bootloader and run at another speed.

Thanks, Charles, I am trying to bootload a micro running on internal oscillator (no external crystal). The configuration fuses were set correctly when the bootloader was installed but the micro defaults to 1 MHz during programming because the OSCCON register is cleared during programming. How can anyone work around this and load a micro without an external crystal?

Hey Sunflower,

Since Mecanique's bootloader code is in hex form, I don't see a way to insert an osccon command, but maybe I am missing something.

Since it doesn't seem important which bootloader they use, in this case, I would use Tiny Bootloader: http://www.etc.ugal.ro/cchiculita/so...bootloader.htm . You can add the changes you need into the assembly source, then compile.

If I understand your project, you currently have it running on a Basic Stamp, but you need to do it cheaper, so you are turning to PBP. You say you wanted each location to have a copy of PBP and MCSP. But did not want to put a crystal on it, because it cost too much. Something doesn't add up?

Basic Stamp II $49.00
PBP + MCSP + PIC18F4620 = $304.90

Difference = loads of crystals

Thanks. Perhaps we could plant code in space reserved but not used in bootloader space that would drive the micro at 4MHz internal before programming. (I could not do that, never assembled anything.)

Cheaper to fix the software than to buy crystals.

Cheaper by the thousands. Basic Stamp is a great R&D platform. $5 PIC (plus lower power and more peripherals) would stomp Stamp prices in production.

Quote:

---

Originally Posted by SUNFLOWER

Cheaper by the thousands. Basic Stamp is a great R&D platform. $5 PIC (plus lower power and more peripherals) would stomp Stamp prices in production.

---

It is not clear that you have added the cost of PBP and MCSP in the equation?

Quote:

---

The solar tracking code will be open source for places like India and China, posted in user-friendly BASIC. They hopefully will only need PBP + MC Studio Plus for local integration.

---

I know this concerns meLabs. Once compiled mass production begins. So meLabs only get paid per software development workstation, not per dish. That is the future. For now, multiple startups will require PBP for developing their proprietary Dish_Operating_System.hex. Our kernel DOS is open source as a starting point. We have bigger fish to fry.

MicroChip Bootloader P1618QP.EXE and Tiny_Loader both have the same conflict with internal oscillators and bootloaders.

Anyway, I think I need help to jump past bootload space, set one bit OSCCON.5 = 1, then jump to the start of bootload and program at 4 MHz. I would be forever grateful.

For what it's worth, I've had good success with Mechanique in politely asking for "special" loader hex files. Mine were for the 18F1220 and 18F1320 using the internal oscillator at 4 and 8 MHz (so a total of 4 files). That was a few years ago.

So have you emailed Mechanique and asked? I really don't think it's a huge deal on their part.

Best Regards,
Paul

I assume posting code would violate some sort of copyright, but I have modified MCLOADER to do all sorts of different things.

If you are brave, you can dissassemble the .HEX file and look for where it sets up the USART Change those (probably two) 'movlw' lines and re-assemble.

Open MPLAB, import the .HEX file and choose VIEW MEMORY. Although there is probably an easier way, I set up a "send print to file" printer and chose <CTRL><P> to save the dissasembly as txt.

Use a DIFF program (I use ARAXIS) to compare the 20MHz and the 4MHz bootloaders. The rest is easy.

Thanks Charles. If I had fear I would not be here. I did not know what a PIC was two weeks ago.

I had engineers before the economy went into a coma. My skill set will not assemble and am at the mercy of strangers.

Yes, prstine, I saw (your?) post from years ago and wrote Mechanique. I am surprised this problem persists. I am old enough to remember using slide rules in physics class. Friends were flipping switches on the Altair while I was using the mainframe to design geodesic dishes. It was then that I heard, "Time is mother nature's way of preventing everything from happening at once". So I hope in good time these loaders will become more flexible.

Thanks for all the responses.

Best,
Doug

If it is useful for you, you can modify the bootloader after it is installed. Your program can erase FLASH (with the ERASECODE) instruction.

You have to look at the erase block size for your chip (probably 64 bytes), and (in this case) start on a 64 byte boundary. That will erase 64 sequential bytes. Then you write back the new data with the WRITECODE instruction. The WRITE block size may or may not be the same size as the ERASE block size.


I had a customer who felt that the bootloader was a security breach, and wanted to run it only when a jumper was installed. The boards were installed and couldn't be returned. I had very few free pins.

My code wrote to the CONFIG register and turned MCLR into an in input, then it read and changed the jump vector at location 0 to a point in memory ABOVE MCLoader. There, I had a routine that checked for the the MCLR line to be low, if it was, I jumped to the MCLOADER entry point, if not, I jumped back to my program and bypassed the bootloader.

I know this isn't a forum for "war stories" but my wife and friends don't understand any of this!

Quote:

---

Originally Posted by SUNFLOWER

MicroChip Bootloader P1618QP.EXE and Tiny_Loader both have the same conflict with internal oscillators and bootloaders.

---

Yes they do. But with Tiny Bootloader, they give you the source code, so you can change anything you want. Although, Charles has me interested about disassembling the MCLoader files! Thanks Charles, I will try that!

Here is a modified Tiny Bootloader. Untested, but here are the changes I made.

Code:

---

    radix DEC
    LIST      P=18F4620    ; change also: Configure->SelectDevice from Mplab
xtal EQU 4000000        ; set for 4 mhz you may want to change: _XT_OSC_1H  _HS_OSC_1H  _HSPLL_OSC_1H
baud EQU 9600            ; the desired baud rate
    ; The above 3 lines can be changed and buid a bootloader for the desired frequency (and PIC type)
   
    ;********************************************************************
    ;    Tiny Bootloader        18F series        Size=100words
    ;    [email protected]
    ;    http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
    ;********************************************************************
   

    #include "icdpictypes.inc"    ;takes care of: #include "p18fxxx.inc",  max_flash, IdTypePIC
    #include "spbrgselect.inc"    ; RoundResult and baud_rate

        #define first_address max_flash-200        ;100 words
    __CONFIG _CONFIG1H, _OSC_INTIO67_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
    __CONFIG _CONFIG2L, _PWRT_OFF_2L & _BOREN_OFF_2L
    __CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_1_2H
    __CONFIG _CONFIG3H, _MCLRE_ON_3H & _PBADEN_OFF_3H & _CCP2MX_PORTBE_3H
    __CONFIG _CONFIG4L, _DEBUG_OFF_4L & _LVP_OFF_4L & _STVREN_OFF_4L & _XINST_OFF_4L
    __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L
    __CONFIG _CONFIG5H, _CPB_OFF_5H
    __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L
    __CONFIG _CONFIG6H, _WRTB_OFF_6H & _WRTC_OFF_6H
    __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L
    __CONFIG _CONFIG7H, _EBTRB_OFF_7H & _DEVID1 & _IDLOC0


;----------------------------- PROGRAM ---------------------------------
    cblock 0
    crc
    i
    cnt1
    cnt2
    cnt3
    counter_hi
    counter_lo
    flag
    endc
    cblock 10
    buffer:64
    endc
   
SendL macro car
    movlw car
    movwf TXREG
    endm
   
;0000000000000000000000000 RESET 00000000000000000000000000

        ORG    0x0000
        GOTO    IntrareBootloader

;view with TabSize=4
;&&&&&&&&&&&&&&&&&&&&&&&  START    &&&&&&&&&&&&&&&&&&&&&&
;----------------------  Bootloader  ----------------------
;PC_flash:        C1h                U        H        L        x  ...  <64 bytes>  ...  crc   
;PC_eeprom:        C1h                  40h  EEADR  EEDATA    0        crc                   
;PC_cfg            C1h            U OR 80h    H        L        1        byte    crc
;PIC_response:      type `K`
   
    ORG first_address        ;space to deposit first 4 instr. of user prog.
    nop
    nop
    nop
    nop
    org first_address+8
IntrareBootloader
                            ;init serial port
    movlw b'00100100'
    movwf TXSTA
    movlw spbrg_value
    movwf SPBRG
    movlw b'10010000'
    movwf RCSTA

    movlw b'01100000'        ;ADDED to set osccon to 4mhz internal
    movwf OSCCON
                            ;wait for computer
    rcall Receive           
    sublw 0xC1                ;Expect C1h
    bnz way_to_exit
    SendL IdTypePIC            ;send PIC type
MainLoop
    SendL 'K'                ; "-Everything OK, ready and waiting."
mainl
    clrf crc
    rcall Receive            ;Upper
    movwf TBLPTRU
        movwf flag            ;(for EEPROM and CFG cases)
    rcall Receive            ;Hi
    movwf TBLPTRH
        movwf EEADR            ;(for EEPROM case)
    rcall Receive            ;Lo
    movwf TBLPTRL
        movwf EEDATA        ;(for EEPROM case)

    rcall Receive            ;count
    movwf i
    incf i
    lfsr FSR0, (buffer-1)
rcvoct                        ;read 64+1 bytes
        movwf TABLAT        ;prepare for cfg; => store byte before crc
    rcall Receive
    movwf PREINC0
    decfsz i
    bra rcvoct
   
    tstfsz crc                ;check crc
    bra ziieroare
        btfss flag,6        ;is EEPROM data?
        bra noeeprom
        movlw b'00000100'    ;Setup eeprom
        rcall Write
        bra waitwre
noeeprom
        btfss flag,7        ;is CFG data?
        bra noconfig
        tblwt*                ;write TABLAT(byte before crc) to TBLPTR***
        movlw b'11000100'    ;Setup cfg
        rcall Write
        bra waitwre
noconfig
                            ;write
eraseloop
    movlw    b'10010100'        ; Setup erase
    rcall Write
    TBLRD*-                    ; point to adr-1
   
writebigloop   
    movlw 8                    ; 8groups
    movwf counter_hi
    lfsr FSR0,buffer
writesloop
    movlw 8                    ; 8bytes = 4instr
    movwf counter_lo
writebyte
    movf POSTINC0,w            ; put 1 byte
    movwf TABLAT
    tblwt+*
    decfsz counter_lo
    bra writebyte
   
    movlw    b'10000100'        ; Setup writes
    rcall Write
    decfsz counter_hi
    bra writesloop
waitwre   
    ;btfsc EECON1,WR        ;for eeprom writes (wait to finish write)
    ;bra waitwre            ;no need: round trip time with PC bigger than 4ms
   
    bcf EECON1,WREN            ;disable writes
    bra MainLoop
   
ziieroare                    ;CRC failed
    SendL 'N'
    bra mainl
     
;******** procedures ******************

Write
    movwf EECON1
    movlw 0x55
    movwf EECON2
    movlw 0xAA
    movwf EECON2
    bsf EECON1,WR            ;WRITE
    nop
    ;nop
    return


Receive
    movlw xtal/2000000+1    ; for 20MHz => 11 => 1second delay
    movwf cnt1
rpt2                       
    clrf cnt2
rpt3
    clrf cnt3
rptc
        btfss PIR1,RCIF            ;test RX
        bra notrcv
        movf RCREG,w            ;return read data in W
        addwf crc,f                ;compute crc
        return
notrcv
    decfsz cnt3
    bra rptc
    decfsz cnt2
    bra rpt3
    decfsz cnt1
    bra rpt2
    ;timeout:
way_to_exit
    bcf    RCSTA,    SPEN            ; deactivate UART
    bra first_address
;*************************************************************
; After reset
; Do not expect the memory to be zero,
; Do not expect registers to be initialised like in catalog.

            END

---

Thanks scalerobotics. It worked crystal clear... only once. After that Tiny_bootloader could not find PIC unless it was totally erased, Tiny bootloader reloaded, then Tiny found PIC and Tiny programmed PIC, only once, then round we go again. So there is a conflict somewhere in the fog...

Best,
Doug

Quote:

---

It must be dirt cheap

---

If you're not using a crystal just to keep costs down, why not get rid of the MAX IC, DB-9 connector, supporting caps, and just design-in a 5-pin header for in-circuit programming?

The PGD and PGC pins could be used for serial communications if you need to monitor what's happening on the board.

If this board will be installed outdoors, you're most likely going to have issues when attempting to boot-load new firmware anyhow due to changes in temperature. The internal osc is fine when indoors, but when exposed to extreme temp changes it will drift considerably, and you will have major problems just trying to load new firmware.

You won't have that problem with in-circuit programming. A Pickit2 could be used for firmware updates & as the serial monitor if needed, and a Pickit2 costs even less than MCS+.

Your board is a lot less expensive, and your programming tool is less expensive + more reliable, and you can use any internal osc speed you prefer.

Hmmm,

Did you have

Code:

---

define loader_used 1

---

At the top of your program? This tells PBP to skip the first four locations (I think), which are necessary for the bootloader.

Yes did that, and it did work once, tantalizingly close to crystal freedom.

We have some boards that are too small for an additional MAX232 chip. We bring out the Tx and Rx pins anyway (along with Vcc and GND). When programming is needed, we plug in a board that has a MAX232 chip and a DB9 connector on it.

So we can have a bootloader AND a small, low-cost board.

The real upside is that having a serial port is one of the best debugging tools around.

The boards start up at 4Mhz, but the code "downshifts" to 1Mhz for power savings. It is a tiny temperature sensor, and any dissipation shows up as a temperature error. The chips are 18F2321s and run on the internal oscillator only.

Yes Bruce I was going down that road eliminating the MAX232 until I considered the advantages of loader-free possibilities with boots. Firmware updates will be all over the map, some in the most remote areas of India. And they are religious about not spending money. So I thought eliminating loaders, like U2, would be a good trade-off for using the MAX232 (and I really like hardware serial functions HSEROUT/HSERIN). I did read Mecanique worries about internal oscillation drift, so maybe if we want to eliminate programming hardware we should just work with crystals, totally not needed for tracking a slow moving sun. Will defer until the industry matures and PICs operating crystal-free can be reliably bootloaded. It is amazing how much stuff is unexpected.

It would be great if PICs also had internal voltage regulators and internal MAX232. Maybe someday.

Thanks,
Doug

Good ideas, Charles, I will consider that type of connection. So you bootload with internal oscillation, what ambient temperatures, and do you experience bootloader reliability issues?

Being user-friendly is very important. I agree that the serial port is useful. Olimex makes a PIC carrier board with the all the needed peripherals for (I hope) less than $10 at scale.

We have chamber-tested random units at -40C and 100C, about 30 units total.

Never any failures.

I assure you, you won't have any trouble at any temperatures humans would want to be at for any length of time.

About 90% of what we do is military. Reliability is important to them, too.

OK good Charles, that settles it. Now to solve that software problem of setting one OSCCON bit in bootleg.hex... I will let the forum know when I hear back from Mecanique.

Hacking Tiny boot was a good idea. Maybe pointing was absolute someplace and did not like inserts, or the program stepped on its tail, or something.

Best,
Doug

Yeah, I think you are right, somehow its stepping on its tail. If you would like, you could read the chip after it steps on its tail, and send me the hex. I'll try to see what's going on with it.:eek:

Do not have time to manage attachments, got a dinner date, but the before and after look the same... and now Tiny does not find target after successfully loading test program. [before and after hex files]

0000- ef00 f07f ffff ffff ffff ffff ffff ffff


ff30- ffff ffff ffff ffff 0000 0000 0000 0000
ff40- 0e24 6eac 0e19 6eaf 0e90 6eab 0e60 6ed3
ff50- d846 08c1 e153 0e4f 6ead 0e4b 6ead 6a00
ff60- d83e 6ef8 6e07 d83b 6ef7 6ea9 d838 6ef6
ff70- 6ea8 d835 6e01 2a01 ee00 f009 6ef5 d82f
ff80- 6eec 2e01 d7fb 6600 d01f ac07 d003 0e04
ff90- d81e d018 ae07 d004 000c 0ec4 d818 d012
ffa0- 0e94 d815 000a 0e08 6e05 ee00 f00a 0e08
ffb0- 6e06 50ee 6ef5 000f 2e06 d7fb 0e84 d807
ffc0- 2e05 d7f5 94a6 d7c9 0e4e 6ead d7c8 6ea6
ffd0- 0e55 6ea7 0eaa 6ea7 82a6 0000 0012 0e03
ffe0- 6e02 6a03 6a04 aa9e d003 50ae 2600 0012
fff0- 2e04 d7f9 2e03 d7f6 2e02 d7f3 9eab d79c


0000- ef00 f07f ffff ffff 0f40 6e01 0b7f bc01


ff30- ffff ffff ffff ffff efb8 f001 ffff ffff
ff40- 0e24 6eac 0e19 6eaf 0e90 6eab 0e60 6ed3
ff50- d846 08c1 e153 0e4f 6ead 0e4b 6ead 6a00
ff60- d83e 6ef8 6e07 d83b 6ef7 6ea9 d838 6ef6
ff70- 6ea8 d835 6e01 2a01 ee00 f009 6ef5 d82f
ff80- 6eec 2e01 d7fb 6600 d01f ac07 d003 0e04
ff90- d81e d018 ae07 d004 000c 0ec4 d818 d012
ffa0- 0e94 d815 000a 0e08 6e05 ee00 f00a 0e08
ffb0- 6e06 50ee 6ef5 000f 2e06 d7fb 0e84 d807
ffc0- 2e05 d7f5 94a6 d7c9 0e4e 6ead d7c8 6ea6
ffd0- 0e55 6ea7 0eaa 6ea7 82a6 0000 0012 0e03
ffe0- 6e02 6a03 6a04 aa9e d003 50ae 2600 0012
fff0- 2e04 d7f9 2e03 d7f6 2e02 d7f3 9eab d79c

Yup, line ff30 did change. Maybe it is Tiny PIC reset after programming. The PIC does reset after programming.

I had a PIC18F4620 laying around, so I tried the code here. The Tiny Bootloader with internal osc seems to work fine here. I don't get an overwrite of my FF30 line though. Is your code very large, or is it writing to locations of the code space?

Also, this may be dumb, but Tiny bootloader will automatically see your chip the first time, without you having to reset the device. After you have used it to load your chip with your code the first time, you will have to reset power within one second of pressing the write button.

Scalerobotics, I am eternally grateful.

I spent the last few hours compiling many changes to tinybld 18F4620.asm (configuration fuses, boot space, hex files, etc.). The new bytes in FF30 were just the first words of my program relocated to make space for the boot call.

I Just now discovered what you wrote above... reset not initially needed but then it is after the first program loaded. Your Tiny hack is working perfectly.

It is good to have open source boots for hungry people.

THANK YOU!

Doug

Not a problem Doug, glad it worked for you. By the way I love your project. http://www.harbornet.com/sunflower/pvdish.html

Charles and Bert have convinced me as well. So my next project will run on internal oscillator.

And for those really cheap, small projects, you can get away without a max232 chip with another modification to the source code. http://www.picbasic.co.uk/forum/show...2538#post82538

Walter

Edit: Here I am with my solar install: Attachment 5221

Quote:

---

Originally Posted by scalerobotics

Charles and Bert have convinced me as well. So my next project will run on internal oscillator.

---

Nice to know I can convince someone of something :)

welcome to the "inside"

California solar, kudos scalerobotics. The solar dish is a dangerous autonomous robot. It must know where the sun is from a clock time/date algorithm and where the dish points. Otherwise, if the sun suddenly appears from behind a cloud then a rebel dish could melt rocks or start fires. I was once set on fire by walking into the invisible beam. It was like being hit with a 10 kW laser.

It appears the dish control system will cost $15, plus sensors $? and Pololu dual motor Hbridge TB6612FNG $8 for one.

The MAX232 is not so dear. Olimex make a populated PIC 40 carrier board ~ 1 @ $17, or 150 @ $13, or thousands w/o crystals @ <$10. Includes PIC 40 socket, MAX232, DB-9 plug, LM317 +3.3V / +5V power, status led, push button, 20 MHz crystal, reset button, ICSP, and circuit area for things like a DS1307 clock. Looks good for production start up with easy scale up.

http://www.olimex.com/dev/pic-p40.html

The business model is mass production from existing mass produced materials and parts all installed/maintained globally via local integration without central command and control. Local return on investment must be 20% (without subsidies) compared to current natural gas prices.

The huge and urgent objective is international global warming mitigation.

Best,
Doug

Charles,

Quote:

---

We have chamber-tested random units at -40C and 100C, about 30 units total.

---

Were you testing this by boot-loading with the internal osc and a serial loader, or just testing to see if the PIC failed at these temps?

If so - which PIC were you using? I've had problems in Colorado when the temperature fell below freezing with serial loaders using the internal osc. And more when the board was in an enclosure exposed to direct sun.

Just curious. That's pretty good if you were boot-loading with a serial loader using the internal osc at these temperatures.

Quote:

---

Originally Posted by SUNFLOWER

Otherwise, if the sun suddenly appears from behind a cloud then a rebel dish could melt rocks

---

Melting Rocks = Cool!!;)

Quote:

---

The huge and urgent objective is international global warming mitigation.

---

Very Cool!!

Quote:

---

I was once set on fire by walking into the invisible beam. It was like being hit with a 10 kW laser.

---

Most uncool!:mad:

Very nice project indeed. (And don't forget to wear your sun block!)

Solar melted rocks made great visitor gifts.

We flashed hot dogs on sticks into carbon but could not get a marshmallow hot. The rules at Federal solar concentrator sites include, "Always wear white clothes and white caps".

Quote:

---

Originally Posted by Bruce

Charles,


Were you testing this by boot-loading with the internal osc and a serial loader, or just testing to see if the PIC failed at these temps?

If so - which PIC were you using? I've had problems in Colorado when the temperature fell below freezing with serial loaders using the internal osc. And more when the board was in an enclosure exposed to direct sun.

Just curious. That's pretty good if you were boot-loading with a serial loader using the internal osc at these temperatures.

---

We were not actually boot-loading at those temps. We were, however, continuously doing serial I/O at 19,200 baud. No problems. Note that we were using 18LF2321's at 5V.
Many years ago, I found that some other chips (in the 16F series) were not nearly so accurate - or stable.

Thanks Charles. I'll have to try an 18F part. I had tested this with 16F types. Never thought there would be that much difference with the internal osc on an 18F type, but I will test it. Solid comms with the internal osc at those temps is pretty amazing.

Different parts have different tolerances on the oscillator. Some of the newer 18F parts are really good.

Received email from Mecanique --

Hi

We only supply loader hex with external OSC. You might want to take a look at

http://mrmackey.no-ip.org/elektronik/ds30loader/

which may better meet your needs...

regards



Open source "ds30 loader" PIC bootloader supporting PIC16, PIC18, PIC24, and dsPIC