18F2550 and ICSP

[Malc C]

Guys,

I'm stummped (yeah I know, easy to do :) ) - I've built a small development board and included the connections so that I didn't have to keep on removing the PIC from the programmer. However whilst the 18F2550 programs fine in the programmer, it fails to program via the ICSP connection.

Thinking it was my PCB I breadboarded just the chip and the connections (VPP, VDD, GND, CLK and DTA to the pins as per the datasheet - still the device failed to load the HEX file. I then double checked the ICSP by programming a 12f765 with a simple HEX file and it worked fine.

The programmer is an Olimex PG-02 which is based on the JDM programer schematic, and like I've already stated, programmed the PIC fine when the PIC is directly inserted. I've checked the web for any information on how to configure the 18F2550 for ICSP and can't find any information. Can any of you experienced PIC programmers shed any light. (I've also tried three different programming software - WinPIC pro, PICPgm and winpic 800 and all do the same)

Cheers

[Mr.RC-CAM]

The ICSP programmer must have enough current to power the PIC and whatever else is in the project's circuit. Hobby programmers have limited drive current because they are usually powered by the PC's port. Perhaps yours cannot source enough for your board.

Other than that, post your circuit and perhaps someone will see if there is anything that would explain the problem. For example, things like the MCLR pin must be connected to external circuits with care in ICSP apps.

[Malc C]

Thanks for the reply,

In order to illiminate that possible cause I breadboarded just the PIC with the 5 wires going to their respective pins - no other components involved. Yet the same thing happened.

You keep saying "hobby programmers", the PG-02 is a commecrially made item by Olimex and sold through Sparkfun

I measured the voltage on MCLR and it's rased from around 7v dc to over 13v dc, so should (in theory) switch the PIC into programming mode ? - something which it does when the PIC is inserted into the paralleld DIL socket on the programmer. - I was just wondering if the 18F2550 required other pins to be grounded (already tried RB5) or something to ensure switching to program mode ?

[Mr.RC-CAM]

I breadboarded just the PIC with the 5 wires going to their respective pins - no other components involved. Yet the same thing happened.Just so we are on the same page, you removed ALL the board's components and ALL the external connections to the PIC, except the five ICSP wires? Even an innocent part on the target can be involved. So, do you have anything remaining in the circuit or connected externally to the PIC?

You keep saying "hobby programmers", the PG-02 is a commercially made item by Olimex and sold through SparkfunThe PG-02 is a definitely a hobby programmer. These designs serve their purpose but do not work well in all applications. The freeware software is also often a source of bugs that can cause temperamental operation on some PIC's.

I was just wondering if the 18F2550 required other pins to be grounded (already tried RB5) or something to ensure switching to program mode to ensure switching to program mode ?You need only the five connections, nothing more. In the case of the Olimex and its variants, all programming is done "ICSP" style using the five connections. The only difference is that in one case it is using the local socket, in the other case it is done remotely at the end of the five wires.

If your target board has zero components on it other than the PIC, then the difference would be the ICSP wires and how you connected them. If the wires are long then crosstalk can become a problem.

[Malc C]

Hi,

Yes that is correct - the breadboard simply contained the PIC and no other components or connections other than the five links from a 5 way header pin to the VPP, VDD, GND, CLK and DATA pins. The jumper cable from the programmer to the breadboard is 20cm long ribbon cable

The PIC can be programmed onboard the programmer - removed and placed in the breadboard and connected via the ICSP cable and the HEX read back OK - but can not be made to go into programming mode via ICSP cable, regardless of what software is used.

Its really got me stumpped !

[Mr.RC-CAM]

the breadboard simply contained the PIC and no other components or connections other than the five links from a 5 way header pin to the VPP, VDD, GND, CLK and DATA pins. There are two grounds on the PIC (8,19). Are they tied together? BTW, what PIC pins are you using for each of these signals?

The jumper cable from the programmer to the breadboard is 20cm long ribbon cable I suspect that the ribbon cable is the problem. The Olimex does not buffer these signals so they are probably experiencing crosstalk. As an experiment, remove the ribbon cable. Connect the ICSP using five individual wires that are under 10 cm long and try again. If that does not help then it might help to post some detailed photos of your board and ICSP setup.

[Malc C]

Ok I've tried the suggestion to illiminate the ribbon cable

I've used single strands of wire and connected the PIC pin for pin to Vdd, Vpp, GND, RB6 and RB7 (pins 20, 1, 8&19, 27 and 28) and that too failed, but this time it seemed to program the first few lines of code and then bomb out.

I've attached images if that helps ?

The dtarnge thing is I can change the PIC for a 12F675, and swap the ICSP wires over to the relevent pins and squirt some hex to it without problems. I've also used the same ICSP ribbon cable to program 16F877a chips too... :confused: :confused:

[Mr.RC-CAM]

Yup, it is a weird problem. Have you tried installing a decoupling cap on your breadboard? Try a .1uF from Vcc to ground (pins 19 & 20), as close to the PIC as possible.

Other than that, I suspect a timing violation in the programmer. With the breadboard setup, try another freeware programming software app.

[Malc C]

Yup, it is a weird problem. Have you tried installing a decoupling cap on your breadboard? Try a .1uF from Vcc to ground (pins 19 & 20), as close to the PIC as possible.

Tried that and still no joy - :(

Other than that, I suspect a timing violation in the programmer. With the breadboard setup, try another freeware programming software app.

Tried three of the more popular freeware apps and still no joy. One of the apps (http://members.aon.at/electronics/pic/picpgm/ ) will actually recognise the PIC when its plugged into the programmer on initialzation, but via the ICSP reports ????? which makes me suspect that the PIC requires some other pin either grounded or pulled up at the time of power up ??

Thanks for all your help though

[Mr.RC-CAM]

...which makes me suspect that the PIC requires some other pin either grounded or pulled up at the time of power up ??I use the ICSP port on several different PIC18F series parts. The five wires are all I use. The programmer is a LabTool-48XP.

Long ago I ran into a problem with a low cost programmer/ICD. It would not program the PIC using ICSP unless I grounded the PIC's Analog Inputs. I suspect it was a side affect of the low cost programmer hardware or perhaps just bad karma.

[Malc C]

Looking on the track side of the programmer thses are the pin connections (DIL Socket)

VPP - pin 1
Vdd - pins 11, 12,13,14,20, 25
Gnd - pins 4, 5,6,7,8,17,19,24
RB7 - pins 28, 22, 16
RB6 - pins 27, 23, 15

All other pins are not connected

The schematic can be seen below

http://www.olimex.com/dev/images/pic-pg2c-sch.gif

Sv2 and SV3 represent the inner DIL socket

[Mr.RC-CAM]

If you want to unravel this onion, you could just plug in more jumper wires until the programming works. That way you can identify which extra wire(s) your programmer needs to function. Better still, you could report what you find to the vendor so that they could work on a permanent fix.

If more wires do not help then this is a timing or signal level issue. Some programming apps have config menus to alter the timing. But, the signal levels are at the mercy of your PC's comm port on these simple hobby programmers. You would not be the first to suffer from such issues.

[icedog]

How about to try parallel port ICSP programmer?

for eg, P16pro or this one http://alessioandrea.altervista.org/pdf/picprog_schem.pdf

[Mr.RC-CAM]

I measured the voltage on MCLR and it's rased from around 7v dc to over 13v dc, so should (in theory) switch the PIC into programming mode ?FWIW, this is a violation. Per the mfg data sheet, the programming voltage must not exceed 12.5VDC. Maybe a 10K resistor to gnd would load it to a proper Vpp voltage?

Edit: Also, please see the heading "PGD to PGC Crosstalk" at this site: http://www.embedinc.com/picprg/icsp.htm

.

[Chippie]

Malc,

FWIW, I too have suffered from the non ability to icsp for even the simpler 16F628s.....

I have a Velleman programmer that has dedicated supplies for the Vcc and Vpp voltages, thus taking the load off the serial ports when it comes to generating the programming voltages. It has a header for icsp but I've not had any success in programming in-circuit while trying to develop a tacho program...

I'd be interested in a fix for this..I've no further ideas. :(

[LukeZ]

Malc C, I've also used the PG2 from SparkFun. I've had very patchy success with it. It is definitely underpowered - I always have to supply board power for it to work, but even then it's intermitent. And, the ICSP cable always gets hot to the touch when programming. Maybe excessive current flow from diferent ground potentials, I don't know. Anyways it's not been a steady hitter. For software I've been using ICProg.

For what it's worth, I've always used a 10k resistor that connects Pin 1 of the PIC to Gnd, as Mr. RC-Cam mentioned. Not sure where I saw this but that's what I do.

Recently I broke down and bought SparkFun's Tiny ICD2-compatible (http://www.sparkfun.com/commerce/product_info.php?products_id=6) programmer. It's cheaper than a real ICD2 but is still kind of expensive. But at least it works with the whole line of chips, whereas ICProg didn't.

But hey, completely aside from ICSP, have you considered using a bootloader? I recently discovered this concept and oh boy, has it ever changed my life. What a blessing. You only need to flash the bootloader onto your PIC once, which you could do with your PG2 by using the socket, since you say you have success with that route. After that all re-programming is done through your PIC's onboard UART. You'll need a Max232 circuit, which takes up valuable bread-boarding real estate, but I keep all that off-board by using a programming cable that has a level shifter (http://www.acroname.com/robotics/parts/S13-SERIAL-INT-CONN.html) attached.

I've been using Tiny Bootloader (http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm), which supports your chip, the 18F2550. Another wonderful advantage of the bootloader is that it only takes a couple seconds to flash your chip, rather than the minutes involved through ICSP.

Just a thought.


Luke

[Malc C]

Luke,

Thanks for your comments. I must admit that I haven't experienced any of the isues with the PG2C's cable, but then again I have never had the circuit externally powered at the same time as programming having read their warning in the spark fun tutorial on ICS programming.

No I have not tried a bootloader. I do have a Max 232 laying around so I might give that a go. I'll have to swat up on the 18F2550 data sheet, but would the UART be via the USB connection, which given the fact that most programmers are RS232 serial and not USB creates a problem ?

[LukeZ]

Malc, no, you can use the bootlaoder with a standard serial port. In fact I believe that's the only method Tiny Bootloader works. There may be others that can implement the USB port, but given that the receiving end is a PIC there would be a USB-RS232 somewhere in there.

At the bottom of this page on the Tiny site (http://www.etc.ugal.ro/cchiculita/software/tinybldusage.htm) is a schematic showing the hookup from PC serial port -> Max232 -> PIC. You can see it's pretty straightforward.

If you decide to try it feel free to post any issues you have and I'll be happy to help you figure it out.


Luke

[Malc C]

I'm going to modify the "development" board to incorporate the MAX 232 and have a bash at using that bootloader. Luke mate, thanks for the offer of help, I'm sure I'm gonna need it :)

[LukeZ]

Malc, I just checked out your chip. I hadn't known it had a USB port on-board. All the same, it looks like from Tiny Bootloader's sample .asm file for this chip (tynibld18F2550usb.asm - in the picsource\18f\ folder) still uses the regular EUSART on PortC.

I don't know what you're coding in - I'm using Microchip's C18 C compiler. If you're using that, and have your toolsuite set up that way in MPLab, you'll have to change the __Config statements in the above asm file to correspond with the new syntax used by C18. I can send you more info on that but you may already know it, and you may not even be using C18.

Good luck! Keep us posted.


Luke

[Malc C]

Luke,

This all stemed from the following thread
http://www.rcgroups.com/forums/showthread.php?t=495749

Basically Mark and I are trying to modify the code from the website listed in the first post and make it a 6+6 joystick based on the 18f2550, rather than the current 4+8 arrangement. In order to make things easier (or so we thought !) I developed a small PCB with a USB connector on it (saves having to crawl under the desk eact time to test it) and ICSP header. It was then that I experienced problems uploading the HEX, and hence started this thread.

I'll try and knock up the MAX232 version on a PCB and see how things progress - stay tuned ;)

[Malc C]

Right, I've just done the schematic in Eagle and have the board routed. I'll etch it in the morning and then get the additional bits I need in the afternoon. However I have my first question. The interface uses the USB +5v and GND for its power, and the RS232 port's ground is thus commoned as pin 15 is linked to the PIC's GND. I take it that this should n't cause a problem being fed from the same PC ? I assume that non of the high (+-10v) potential from the RS232 port actually gets to the PIC as the Max232 converts these down to TTL levels ?

[LukeZ]

Aha - reading that thread I see Mr. RC-Cam already mentioned the __CONFIG issue. I guess it's relevant whether you use C18 or not. Anyways you got that part figured out.

I can't be too much help on the code itself - I'm not a big assembly programmer myself.

Are you etching your own PCBs? You can buy small Max232 shifters for about 10 bucks at several places - would be cheaper and faster than sending out a board to a fab house. But if you can etch it yourself then I suppose that would be fastest. :cool:

Also, I'm sure you already knew, but there are several pre-made circuits that allow you to connect your TX to the PC through USB. I'm pretty sure some of them allow more than 4 analog channels. I have one at home that I'll check after work tonight. But I'm guessing you're doing this for the fun of making it yourself. ;)

Luke

[LukeZ]

Boy, you answered my question about the etching even before I asked it! :eek:

You're right that the Max232 converts the standard RS-232 level signals to TTL, so those won't get to the PIC (I mean they will, but they'll be logic level).

However, I'm confused about the USB +5v and Gnd. Are you making a USB to Serial adapter?


Luke

[Malc C]

Luke,

Yes I know there are lots of RC - PC windows joysticks on the market, and quite a few sites that have Schematics and hex files available for download, however they are all based on the 16C745 PIC, which is a one time program device, and also Microchip are probably at some point going to phase out the 745 in favor of the 18F2550. Besides, as you say, where's the fun if its all handed to you on a plate :)

Yes I tend to etch my own PCB's, when they are one offs like this project. - No I'm not making a USB-RS232 convertor, its the USB RC-PC Windows joystick interface from that site. Just that (as far as I can find) this is the only site offering asm, hex etc for the 18F2550, but (as mentioned above) it has just 4+8 config and not 6+6 that we desire

Let me try to explain myself better (hopefully) regarding the USB supply. Under normal circumstances the PIC will be powered from the regulated +5 volt supply from the computers USB port. When I've managed to program other PICs via ICSP I've disconnected the power lead (USB / serial / external supply) as the PIC programmer supplies +vdd (+5v) and GND. However now that I intend to program the PIC via the bootloader and thus have omitted the ICSP connection, the only way to power this test board is via the USB +5v and GND rails. In the schematic in your post it shows pin 5 of the RS232 (gnd) connected to GND on both the MAX232 and PIC, so ergo, pin 5 (GND) is connected to GND of the USB port on the same computer (possibly forming a loop ??) - hope you're with me so far ?

Not knowing if the GND of the Comm port is common to the GND of the USB port, I was concerned that there also might be a potential difference and thus could bu**er up my PC ?? (or am I being paranoid ??)

[LukeZ]

Ok, now I think I'm following you. I wasn't understanding where USB fit into all this, but then I remembered that's the whole point - connect your TX to the PC via USB. Duh!

Well, it's my belief that a PC ground on one connector is the same as PC ground on another, so I don't think you should have any problems with ground differentials. HOWEVER, I'll defer to the real experts on that. I don't want to be responsible for smoking your computer! But I have done essentially what you propose, and I haven't had any problems with it in the past. Nor, might I add, have I ever done it on a PC that I didn't mind losing...

I just now checked the voltage difference between the ground on my serial port and the ground on my USB port - it was about 20-50 mv. Kind of wandered around. Not sure what that tells us exactly... but anyhow they're not precisely the same potential.

I guess if you wanted to get fancy you may possibly be able to power your board from the RTS line on the serial port. Tiny Bootloader has an option to assert this line high while programming (pull high). Of course RTS is 12 volts so you'd need to regulate it to 5. To get really fancy (or maybe really dumb?) it may be possible to "regulate" it by passing it through the extra, unused driver of the Max232. Of course the Max232 inverts signals so in that case you wouldn't want Tiny Bootloader to pull it high, just leave it at the default off. Theoretically then this should give you an appropriate Vcc to work with, but how much current it can source is beyond me.

I'm speaking a bit out of school on this one, so maybe someone with a bit more experience could chime in. My idea might be half-baked... But I guess it shows creativity at least! :rolleyes:


Luke

[Malc C]

Well I've built the board and just need to get the MAX 232 chip (I naffed the removal of the old chip from another PCB - a prime example of why DIL sockets are useful :o ) in the morning. I've tested the USB interface part and that all works fine (using 16C745 and a 6Mhz xtal), and pluging in both the uSB cable and serial cable seemed to have no adverse affect on the PC, so the ground issue doesn't appear to be a problem, however the true test will be when the MAX232 is fitted and I try communicating with both ports !

I've attached an image of the board.. its a bit rough and ready, and not as tightly packed, but then its only for development tetsing and notthing fancy :)

I'll post agian tomorrow (whopps- just seen the time - later today :) ) on how it turns out - Fingers crossed :)

[LukeZ]

I've attached an image of the board.. its a bit rough and ready, and not as tightly packed, but then its only for development tetsing and notthing fancy :)Good lordy! :eek: "Rough and ready"? It looks to me like you did a silkscreen even! Not to get off topic, but maybe you can share your method of etching. The lines look too crisp to be iron-on-transfer, are you using photoresist?


Luke

[Malc C]

LOL - Honestly, I used toner transfer method. I used the back of some Inkjet OHP film and then my secret weapon.... hot roll laminator. The pressure and heat do a giid job of transfering the toner. I then use some toner reactive foil to seal the toner from the ferric chloride.

Onced etched I simply print the mirrored image for the silk screen on the same film, and then line it up (the PCB is 0.8mm so it's really easy to line up the holes), and pass it through the laminator a couple of times. When the toner has been transferred I use white toner reactive foil to simulate the silk screen.

However it took a couple of attempts, as I use a toner re-fill and it doesn't melt as well as the genuine item, so the first few attempts had partial success. Also it depends on the condition of the copper on the board, mine has oxidiesed a bit and too some cleaning. - I'm thinking of building a light box and a couple of UV tubes and trialing the photo etch process, either that or forking out for a new genuine printer cartridge !

Further examples can be found in the following thread:
http://www.rcgroups.com/forums/showthread.php?t=355835

Regds

Malc

[Malc C]

Malc, I just checked out your chip. I hadn't known it had a USB port on-board. All the same, it looks like from Tiny Bootloader's sample .asm file for this chip (tynibld18F2550usb.asm - in the picsource\18f\ folder) still uses the regular EUSART on PortC.

Luke


OK now I'm stumpped !

I've completed the board by adding the MAX232 chip. Connecting up both the USB cable and serial cable the hardware checks out (if I place a pre-programmed PIC in the socket, plug in the correct xtal Windows registers the joystick and I can fly a plane in FMS (yeah whoopie !!). - I'm also getting around +4.7v on pins 17 & 18 (RC6 and RC7).

Voltages on the MAX 232 are

Pin 1....... +7.59
Pin 2....... +9.6
Pin 3....... +2.81
Pin 4 ....... +4.25
Pin 5....... -5.18
Pin 6....... -9.42
Pin 7....... -9.41
Pin 8....... 0v
Pin 9....... +4.97
Pin 10....... +4.61
Pin 11....... +4.61
Pin 12....... +4.98
Pin 13....... -9.22
Pin 14....... -9.41
Pin 15....... 0
Pin 16....... +4.98

I programmed the 18f2550usb HEX file provided and placed it in the test socket on the PCB, but running the tiny software it can't find the chip. I had a look at the asm file and think its because the sample file is for use with a different xtal to get the baud rate or something ?

Any ideas on what I need to change in the asm file to make it work on the 4Mhz xtal I'm using, or will I need to constantly change xtals from 25mhz to 4mhz

[xtal]

I got a very simple xlator circuit somewhere ..uses 1 xistor and 2 resistors
I have used it with great success on a 16c84 servo controller and a terminal emulator.
I'll see if I can dig it up.....

Question do the 2 uart/programming pins have to be dedicated to uart....or can they
[ie] start up used for bootloader,,,,normal used for other??

[Malc C]

Ok, here's an update, I've fitted a 20Mhz xtal based on the line in the asm file

; 20MHzQuartz / 5 * 24 / 4 => 24MHz ; check _CONFIG1

But I still get the same error when trying to communicate with the PIC. It reports that the COMM port is OK but "can't find PIC"

[Malc C]

Question do the 2 uart/programming pins have to be dedicated to uart....or can they
[ie] start up used for bootloader,,,,normal used for other??

I've no idea my friend, this is all new to me too !

[Malc C]

Ok, been doing some reseach on the net, the device that I have is the MAX 232CPE. From what I can find its also classed as a Max232A. Now these devices use 0.1uF caps rather than 1uF caps... would using 1uF capacitors stop the thing from working ?

EDIT:

Ok a quick trip to the component shop and picked up some 0.1uF caps - replaced the 1.0ufF caps and tried again (18F2550 with the 20 Mhz xtal and the default HEX code from the tiny site) and it still couldn't find the PIC

EDIT 2:

OK this is really doing my head in :mad:

Took a brand new virgin 18F2550, erased it and varified it was blank. Then took the config settings from the modified interface asm file that is know to load into the above mentioned PIC without errors.
radix DEC
LIST P=18F2550 ; change also: Configure->SelectDevice from Mplab
; 20MHzQuartz / 5 * 24 / 4 => 24MHz ; check _CONFIG1
xtal EQU 24000000 ; 'xtal' here is resulted frequency (is no longer quartz frequency)
baud EQU 115200 ; the desired baud rate

;************************************************* *******************
; Tiny Bootloader 18F*55 series Size=100words
; claudiu.chiculita@ugal.ro
; http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
;************************************************* *******************
; | 12kW 16kW
; -----+----------------
; 28pin| 2455 2550
; 40pin| 4455 4550
#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 PLLDIV=1, CPUDIV=OSC3_PLL4, USBDIV=2
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
CONFIG PWRT=OFF, BOR=ON, BORV=28, VREGEN=ON
CONFIG WDT=OFF, WDTPS=32768
CONFIG MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=ON
CONFIG STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF ; ICPRT=OFF,
CONFIG CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
CONFIG WRT0=OFF, WRT1=OFF, WRT2=OFF
CONFIG WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR0=OFF, EBTR1=OFF, EBTR2=OFF
CONFIG EBTRB=OFF
IFDEF __18F2550
CONFIG WRT3=OFF, EBTR3=OFF
ENDIF

Generated the HEX file using MPLAB version 7.2 (still haven't updated to the latest version) - no errors

Loaded this file into the PIC via the JDM programmer - all went well and varified with no errors.

Placed the PIC into the test board. Fitted a 20 Mhz xtal, connected the serial cable to COMM 1 and plugged in the USB cable. Confirmed power getting to the PIC and launched the Tiny Bootloader software - clicking on "checkPIC button it still reports that no PIC is found :censored: :mad:

Any suggestions on what next to try before I throw this thing in the bin or attack it with a sledge hammer :eek:

EDIT:

Now I'm totally confussed - I came across the attached schematic for the Max232CPE in the PicKIT documentation - it shows 1uF capacitors are used and not 0.1uF :confused: :confused: :mad:

[LukeZ]

Malc,

Boy, you wake up early (or else we're in different time zones ;) ). But I think I know where your problem lies.

First of all, I don't think the caps are all that critical on the Max circuit. I'm using 1uf on mine but I'm betting that's not your problem.

The issue seems to be with your oscillator settings, combined with your choice of crystal. I need to do a bit more reading of the 18F2550 datasheet, since this PIC is kind of a different beast from most other 18F PICs as a result of implementing hardware USB.

At the very least it looks to me like you need to change CONFIG FOSC=XTPLL_XT to FOSC=HSPLL_HS if you are using a 20mHz crystal. The XT setting is appropriate for 4mHz crystals but anything higher than that and you need to change to HS (high speed).

There may be some other settings a bit off but let me do a bit more reading.


Luke

[LukeZ]

Question do the 2 uart/programming pins have to be dedicated to uart....or can they
[ie] start up used for bootloader,,,,normal used for other??That's a good question - the bootloader only uses them when "bootloading" - after that the pins are free and you're free to use them. You can implement the UART in your code the same as you ever would, the bootloader won't interfere.


Luke

[Malc C]

Evening (or morning depending on your location :) ) Luke,

Glad to hear that the MAX isn't that bothered about the capacitors.

OK I have at my desposal a 20 Mhz, 6 Mhz and 4Mhz xtals. I'm sorry to say that I don't know enought about ASM coding to workout what needs changing to get the timing right, for either of these crystals, hence that's why I cut and pasted the config settings from some code that I knew worked ??

Thanks for the offer of swatting up on the datasheet and assistance in this matter. Hopefully you can come up with a config settings that will work with one of the above stated xtals. If you want to take this off the board, either PM me or (better still) drop me an e-mail.

Cheers

Edit:

I assume that the software is looking for a handshake from the PIC when you click on the checkPIC button, and as it doesn't receive it, reports an error. Is there any means of testing the Max232 to confirm that this is not the problem , or compounding the issue ??

[Malc C]

Another wonderful advantage of the bootloader is that it only takes a couple seconds to flash your chip, rather than the minutes involved through ICSP.


You almost had me there.... :-)

Quick question, assuming I used the 20 Mhz xtal, should i not be able to load the tinybld18F2550usb _20MHz_115200.HEX into the PIC and its should then work ? (it doesn't by the way )

Malc


EDIT:

Ok the only way I know of testing the comms was to use one of the soundcard based oscilloscopes and can confirm that when you click on "check PIC button" a series of pulses are detected on pin 17 of the 18F2550 as the software is polling the pic.

I've also noticed that most other CCts that use a Max chip, don't have a resistor in the TX or RX lines between it and the PIC, where that guys CCT has a 200R resistor in one of the lines (can't remember which one !).

[LukeZ]

Malc,

Ok, I see you're in the UK. That explains the time difference!

Quick question, assuming I used the 20 Mhz xtal, should i not be able to load the tinybld18F2550usb _20MHz_115200.HEX into the PIC and its should then work ? (it doesn't by the way )Well, yes, you should, but the reason it doesn't work (I'm assuming), is because that Hex file was probably compiled from tinybld18F2550usb.asm, which as we know uses the wrong (outdated) configuration syntax. So what you've had to do is redo the CONFIG settings, then recompile, but I think that's where you've made a slight mistake (at least for a 20mHz crystal).

Try changing this line in your asm file:
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
to this:
CONFIG FOSC=HSPLL_HS, FCMEM=OFF, IESO=OFF
There may be some other changes we'll need to make, that I haven't read about yet, but that one at least I can see is incorrect right off the bat.

Now, here's another thing - pin 17 of the PIC is atually the TX pin. Maybe you have these switched. The PC should be sending data to the PIC on pin 18 (RX).

You're right about the "handshake." The way this bootlaoder works is that it's basically just a small bit of code that gets executed before your code. What it does is wait one second, and listen on the RX pin of the UART during that time. If it detects a character "C1" from the computer within that one second, then it sends an acknowledgment back to the PC (I think the letter "K"). At that point then the computer knows it found the PIC and the code-rewriting process can begin. Otherwise if your PIC doesn't see that "C1" in the first second, it goes on ahead and begins your user code, and from then on works as usual. Alternatively, if the computer doesn't see that "K" returned to it, then it spits out an error and says it didn't find your PIC.

The 200 ohm resistor on the RX pin of the PIC isn't necessary, but I don't think it hurts. I believe it's just there to reduce the current on the PIC input. Anyways I'm not using it and don't have a problem.

So I'm at work now, but this evening I will peruse the datasheet and write up the configuration bits that you need - if you haven't gotten it to work by then already.


Luke

[Malc C]

Malc,

Ok, I see you're in the UK. That explains the time difference!

Well, yes, you should, but the reason it doesn't work (I'm assuming), is because that Hex file was probably compiled from tinybld18F2550usb.asm, which as we know uses the wrong (outdated) configuration syntax. So what you've had to do is redo the CONFIG settings, then recompile, but I think that's where you've made a slight mistake (at least for a 20mHz crystal).

Try changing this line in your asm file:
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
to this:
CONFIG FOSC=HSPLL_HS, FCMEM=OFF, IESO=OFF
There may be some other changes we'll need to make, that I haven't read about yet, but that one at least I can see is incorrect right off the bat.

OK I'll wait until you've had time to have a look at the files and come up with the changes, then I'll do them all in one go.

Now, here's another thing - pin 17 of the PIC is atually the TX pin. Maybe you have these switched. The PC should be sending data to the PIC on pin 18 (RX).

I've checked the board, and my schematic.

Pic pin 17 (tx) - MAX pin 11 T1 in
Pic pin 18 (rx) - MAX pin 12 R1 out

My gut feeling is that I have the TX and RX reversed, and need to swap them (so that pin 18 on the pic is connected to pin 11 of the MAX. I'll remove the resistor and brake the track and make up some jumpers and give that ago.

You're right about the "handshake." The way this bootlaoder works is that it's basically just a small bit of code that gets executed before your code. What it does is wait one second, and listen on the RX pin of the UART during that time. If it detects a character "C1" from the computer within that one second, then it sends an acknowledgment back to the PC (I think the letter "K"). At that point then the computer knows it found the PIC and the code-rewriting process can begin. Otherwise if your PIC doesn't see that "C1" in the first second, it goes on ahead and begins your user code, and from then on works as usual. Alternatively, if the computer doesn't see that "K" returned to it, then it spits out an error and says it didn't find your PIC.

The 200 ohm resistor on the RX pin of the PIC isn't necessary, but I don't think it hurts. I believe it's just there to reduce the current on the PIC input. Anyways I'm not using it and don't have a problem.

So I'm at work now, but this evening I will peruse the datasheet and write up the configuration bits that you need - if you haven't gotten it to work by then already.


Luke

Thanks Luke, I'll try and make the change to the PCB, its 10:20pm here in the UK and hopefully post any findings before I retire to bed.

[Malc C]

:mad: :mad: :censored:

I'm giving up !

I've swapped over the connections between pins 17 & 18 of the PIC, installed the latest version of MPLABS (7.31). copied the original tinybld18F2550usb.asm file and removed the original config statements. Copied and pasted the config statements from a known working file, and corrected the BORV value to 3 (as per RC-Cams instuctions in the previous thread mentioned above), changed the LS setting to HS as stated in your post above and compiled the HEX. No problems reported in compiling this file, the config settings are shown below

xtal EQU 24000000 ; 'xtal' here is resulted frequency (is no longer quartz frequency)
baud EQU 115200 ; the desired baud rate

;************************************************* *******************
; Tiny Bootloader 18F*55 series Size=100words
; claudiu.chiculita@ugal.ro
; http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
;************************************************* *******************
; | 12kW 16kW
; -----+----------------
; 28pin| 2455 2550
; 40pin| 4455 4550
#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 PLLDIV=1, CPUDIV=OSC3_PLL4, USBDIV=2
CONFIG FOSC=HSPLL_HS, FCMEM=OFF, IESO=OFF
CONFIG PWRT=OFF, BOR=ON, BORV=3, VREGEN=ON
CONFIG WDT=OFF, WDTPS=32768
CONFIG MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=ON
CONFIG STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF ; ICPRT=OFF,
CONFIG CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
CONFIG WRT0=OFF, WRT1=OFF, WRT2=OFF
CONFIG WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR0=OFF, EBTR1=OFF, EBTR2=OFF
CONFIG EBTRB=OFF
IFDEF __18F2550
CONFIG WRT3=OFF, EBTR3=OFF
ENDIF


Loaded the HEX to the PIC - again no errors and it verified OK.

Inserted the 20 Mhz Xtal and conneted the board up to the comm port and USB ports. Launched the tiny application and clicked on check PIC - ERROR - PIC NOT FOUND :mad: :mad: :censored: :censored:

Anyway - its now 11:15pm and I'm throwing this in the bin until I can be more enthusiastic about this sodding project -

[Malc C]

OK last post before I retire for bed and sleep on this problem.

This is the trace I get on PIC pin 18 (rx) when I click on the "check PIC" button of the Tiny software.

Nothing is reurned from the PIC on pin 17 (tx)

[LukeZ]

Ok Malc, I've done some reading. This is awfully confusing; the 2550 has somewhat strange clock settings because of its USB functionality. The datasheet is not as straightforward as I would have liked it to be, but at any rate I think I know what's going on.

If you want to use a 20mHz crystal we would have needed to make more than the change I mentioned earlier (that was, change FOST=XTPLL_XT to FOSC=HSPLL_HS). We would also have needed to change PLLDIV=1 to PLLDIV=5. So I think that's why the 20mHz crystal never worked.

However, we don't need to use a 20mHz crystal. Since the RC Joystick NG project calls for a 4mHz crystal, and that's what its code was written for, let's go back to using that.

Now, the config settings that you should use will be:


CONFIG PLLDIV=1, CPUDIV=OSC3_PLL4, USBDIV=2
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
CONFIG PWRT=OFF, BOR=ON, BORV=3, VREGEN=ON
CONFIG WDT=OFF, WDTPS=32768
CONFIG MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=ON
CONFIG STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF ; ICPRT=OFF
CONFIG CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
CONFIG WRT0=OFF, WRT1=OFF, WRT2=OFF
CONFIG WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR0=OFF, EBTR1=OFF, EBTR2=OFF
CONFIG EBTRB=OFF
IFDEF __18F2550
CONFIG WRT3=OFF, EBTR3=OFF, CP3=OFF
ENDIF


PLLDIV is equal to 1 because that's the setting appropriate for a 4mHz crystal. FOSC can also now go back to XTPLL_XT because again, that's what we use for 4mHz.

At the very top of your tinybld18F2550usb.asm file there are a few lines that look like this:


radix DEC
LIST P=18F2550 ; change also: Configure->SelectDevice from Mplab
; 20MHzQuartz / 5 * 24 / 4 => 24MHz ; check _CONFIG1
xtal EQU 24000000 ; 'xtal' here is resulted frequency (is no longer quartz frequency)
baud EQU 115200 ; the desired baud rate


We actually don't need to change these. If you want you can change the comment line to this, but it would just be for your own notes, it wouldn't make a difference to the program:

; 4MHzQuartz / 1 * 24 / 4 => 24MHz ; check _CONFIG1


The thing is, because of the particular setup we're doing, even though we use a 4mHz clock, and the example for tinybld uses a 20mHz, the resulting xtal Frequency will be the same (24mHz). This is a function of the CPUDIV configuration bit that we set above. I'm not really explaining it but you can take my word for it. ;)

Ok, so to test it out -

1. Replace whatever config list you have with the one I posted above.
2. Put a 4mHz crystal in your board.
3. Ensure that the Max232 is hooked up correctly to your PIC - I think you got this straightened out, but to be clear, this is how it should go:

Max232 PIC
11 (R1out) - 18 (RX)
12 (T1in) - 17 (TX)



EDIT: The above is wrong. My goof. I didn't even get the labels right. This is the correct setting:

Max232 PIC
11 (T1in) - 17 (TX)
12 (R1out) - 18 (RX)
END EDIT

Everything else about your setup looks ok. Try this and let me know what happens. It should work. :rolleyes:


Luke

[LukeZ]

Malc,

I've gone back over this thread and examined each of your previous attempts. The good news is that none of them should have worked, so your results all along have been what we should have expected. This is a lot better than not knowing what was wrong, thinking everything is set up correctly, and still not having it work.

Actually the closest you got was your first attempt, back with the 4mHz crystal and your original configuration settings. It probably would have worked, too, except the Max232 signals were crossed!

Keep trying and I assure you you'll be happy when you see that bad boy get programmed in two seconds flat. :D


Luke

[Malc C]

However, we don't need to use a 20mHz crystal. Since the RC Joystick NG project calls for a 4mHz crystal, and that's what its code was written for, let's go back to using that.

Glad you checked this, it makes sence otherwise I would have to keep swapping xtals

Now, the config settings that you should use will be:


CONFIG PLLDIV=1, CPUDIV=OSC3_PLL4, USBDIV=2
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
CONFIG PWRT=OFF, BOR=ON, BORV=3, VREGEN=ON
CONFIG WDT=OFF, WDTPS=32768
CONFIG MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=ON
CONFIG STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF ; ICPRT=OFF
CONFIG CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
CONFIG WRT0=OFF, WRT1=OFF, WRT2=OFF
CONFIG WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR0=OFF, EBTR1=OFF, EBTR2=OFF
CONFIG EBTRB=OFF
IFDEF __18F2550
CONFIG WRT3=OFF, EBTR3=OFF, CP3=OFF
ENDIF


PLLDIV is equal to 1 because that's the setting appropriate for a 4mHz crystal. FOSC can also now go back to XTPLL_XT because again, that's what we use for 4mHz.

At the very top of your tinybld18F2550usb.asm file there are a few lines that look like this:


radix DEC
LIST P=18F2550 ; change also: Configure->SelectDevice from Mplab
; 20MHzQuartz / 5 * 24 / 4 => 24MHz ; check _CONFIG1
xtal EQU 24000000 ; 'xtal' here is resulted frequency (is no longer quartz frequency)
baud EQU 115200 ; the desired baud rate


We actually don't need to change these. If you want you can change the comment line to this, but it would just be for your own notes, it wouldn't make a difference to the program:

; 4MHzQuartz / 1 * 24 / 4 => 24MHz ; check _CONFIG1


The thing is, because of the particular setup we're doing, even though we use a 4mHz clock, and the example for tinybld uses a 20mHz, the resulting xtal Frequency will be the same (24mHz). This is a function of the CPUDIV configuration bit that we set above. I'm not really explaining it but you can take my word for it. ;)



I'll take your word for this... ;)


Ok, so to test it out -

1. Replace whatever config list you have with the one I posted above.
2. Put a 4mHz crystal in your board.
3. Ensure that the Max232 is hooked up correctly to your PIC - I think you got this straightened out, but to be clear, this is how it should go:

Max232 PIC
11 (R1out) - 18 (RX)
12 (T1in) - 17 (TX)




OK done all that. The stange thing is I had the pins on the MAX connected correctly in the first place !

Everything else about your setup looks ok. Try this and let me know what happens. It should work. :rolleyes:


Luke

Before I corrected the MAX 232 wiring, I tried points 1 and 2 and sure enough if failed. I then corrected the wiring of the MAX to that stated in your post and tried again. - still failed.

To verify that the xtal is functioning I loaded the joystick ng hex file into the 2550 and on plugging in the USB cable windows responded with the "ding-dong" and control pannel reported a windows joystick present. - so the xtal is working fine, and shows that there are no physical problems with the PIC

I have no idea why the tiny software fails to communicate with the PIC. Ive tried swapping the TX and RX lines from the MAX chip and confirmed that signals are getting through to the PIC, so on the face of it, the hardware checks out. - It still must be something to do with the handshaking in the code

I even e-mailed the contact on the Tiny web site and have yet to receive a reply...

Whats needed (IMO) is a simple bit of code and windows application that can be used to confirm that the communications work. This would then prove with out a doubt that the hardware is fine and the issue is with either the bootloader code, or the tinybldwin software that's the problem

Thanks for giving up so much of your time on this Luke

[Malc C]

Luike,

I'm sure that there are still issues with the bootloader code. There seems to be lots of lines that are remmed out, and some like

Receive
movlw xtal/2000000+1 ; for 20MHz => 11 => 1second delay

that still refer to the 20 Mhz xtal ??

At least one thing is OK, the CCT is as cold as a lump of ice... nothing is getting warm :)

[Malc C]

Waheyyyy ! it works !!!

I have no idea what I done... I checked continuity between the MAX and PIC and all was OK and as you suggested

Max232 PIC
11 (R1out) - 18 (RX)
12 (T1in) - 17 (TX)

Re-programmed the PIC and it all varified OK but still failed to work. so I changed the connections over on the MAX chip so its now

Max232 PIC
11 (R1out) - 17 (TX)
12 (T1in) - 18 (RX)

Connected it up and launched the tiny application - see the attached image :) :)

Thanks Luke for all your help, and to the other members, I'm sorry for boring you lot with this problem :) :)

[Malc C]

Maybe it was short lived and my excitement was premiture ??

I loaded some sample code via the bootloader (ruddy quick !!! ) and then tried to overwrite it and it now can't find the PIC :mad: :mad:

Closed and re-started the appliction and it still errored

OK it looks like the problem of the PIC not being recognised only happens after the bootloader has loaded some code to the PIC. I removed the PIC, erased it, re-programmed the bootloader HEX and connected it to the COMM and USB ports - the device was found on each attempt. I then loaded the interface HEX via the tiny application and then tried seaching for the PIC again and it errored.

I assum its because the PIC is now running the interface code and is no longer looking at the RS232 UART port. Is there anyway to reset the PIC or stop it running the interface code and go back into wait mode so I can communicate with the PIC again - Otherwise it some what defeats the object of being able to re-program the PIC without removing it from the board !

[LukeZ]

Malc,

Ok, it looks like you're getting closer. I'm a bit bothered by that code that you mentioned, I had missed it there all the way at the bottom:

Receive
movlw xtal/2000000+1 ; for 20MHz => 11 => 1second delay
movwf cnt1


I need to look into that and see if it needs to be changed.

But as for your further question, about reseting the PIC so it goes back to wait mode to listen for the computer, you're absolutely right.

What you should do is hook up the Max232 to the PIC and have Tiny Bootloader up and running, but don't power the PIC! What you want to do is click the "Write Flash" button in Tiny and then power the PIC (in your case that would mean plugging in the USB cable). That way the computer is already sending out its signal at the time that the PIC starts up. The PIC should catch this and go into write mode.

Alternatively if you have a reset button on your circuit you can have the PIC be powered and running, plug in the serial cable, click "Write Flash" in Tiny, and then hit the reset button on the PIC.

The point is that sometime during the few seconds that Tiny is sending out pulses, you want your PIC to boot up, since that's the only time it listens for the Tiny Bootloader.

I'll do some more checking on that above-mentioned code - but if you get this to work, then no point in "fixing" it.


Luke

[LukeZ]

Hey, are you using a null modem cable to connect your PC to your Max232? I bet you're not, which is probably why I thought your pins were switched, when in fact they weren't...

Perhaps the switch was occuring on the PC side of the Max. Anyways, you know you have the communication hardware working, so don't change it! ;)


Luke

[Malc C]

What you should do is hook up the Max232 to the PIC and have Tiny Bootloader up and running, but don't power the PIC! What you want to do is click the "Write Flash" button in Tiny and then power the PIC (in your case that would mean plugging in the USB cable). That way the computer is already sending out its signal at the time that the PIC starts up. The PIC should catch this and go into write mode.

Nope that don't want to work - Tiny Bootloader reports Error - can't find the PIC

Alternatively if you have a reset button on your circuit you can have the PIC be powered and running, plug in the serial cable, click "Write Flash" in Tiny, and then hit the reset button on the PIC.


Luke

I'll have to modify the board and fit a reset button to MCLR and give that ago

Cheers

Malc

[LukeZ]

Malc,

You seem to be having no end of hurdles to cross, but it looks like you've made some progress all the same.

The small bit of code you posted earlier, that had a mention of 20mHz, is not something we need to worry about. That's just the countdown timer that waits about 1 second on boot and listens for a command from the PC. The value there is just a number high enough so that as the program counts down it should take about a second. I think that code is fine.

Here are some questions:
1. When you do successfully get a program downloaded to the PIC from Tiny Bootloader, does that program then work? Let's say you download your USB interface program using the bootloader - after programing your chip, and reseting it, does your circuit then do what it's supposed to?

2. If not, maybe you can try to use the Bootlaoder to download a simple blink-led program, and see if it actually blinks the led.

3. Can you tell me exactly what pin numbers on your serial cable attach to which pin numbers on your Max232? And are you using a null-modem cable, or a straight-through cable? A straight through cable is one where each pin on one end of the cable is the same number as the pins on the other end of the cable. A null modem cable crosses a few. You can use either one but you will need to connect it to your Max232 in a different manner depending.


Luke

[Malc C]

Malc,

You seem to be having no end of hurdles to cross, but it looks like you've made some progress all the same.

Tell me about it :rolleyes:



The small bit of code you posted earlier, that had a mention of 20mHz, is not something we need to worry about. That's just the countdown timer that waits about 1 second on boot and listens for a command from the PC. The value there is just a number high enough so that as the program counts down it should take about a second. I think that code is fine.

So if this delay is increased then it would give more chance for the software to check for the PIC.

Here are some questions:
1. When you do successfully get a program downloaded to the PIC from Tiny Bootloader, does that program then work? Let's say you download your USB interface program using the bootloader - after programing your chip, and reseting it, does your circuit then do what it's supposed to?

Yes it does. I can erase the PIC, program it with the bootloader code, insert it into the test board, launch the tiny loader software on the PC, apply power (plug the USB cable in) and click on check pic - 9 out of 10 times the PIC is identified. Then load the Joystick interface code and click "Flash PIC" and the code is sent to the PIC. On completion the interface is recognised by Windows and the joystick is seen in game controllers and works under FMS - However I can't now reset the PIC so that it runs the bootloader software, even with the use of a switch between MCLR (pin 1) and +ve

2. If not, maybe you can try to use the Bootlaoder to download a simple blink-led program, and see if it actually blinks the led.

Not applicable - see above

3. Can you tell me exactly what pin numbers on your serial cable attach to which pin numbers on your Max232? And are you using a null-modem cable, or a straight-through cable? A straight through cable is one where each pin on one end of the cable is the same number as the pins on the other end of the cable. A null modem cable crosses a few. You can use either one but you will need to connect it to your Max232 in a different manner depending.


Luke

The MAX is connected to a 9 way PCB mounted male 9 way D type plug.

max 232 pin 13 - Plug pin 3
max 232 pin 14 - Plug pin 2

GND - Plug pin 5


The board is then connected to the PC's COMM1 port via a straight serial cable.

Hope this helps ??

[LukeZ]

The MAX is connected to a 9 way PCB mounted male 9 way D type plug.

max 232 pin 13 - Plug pin 3
max 232 pin 14 - Plug pin 2

GND - Plug pin 5

The board is then connected to the PC's COMM1 port via a straight serial cable.

That is correct. You have it right.

Also, I looked back at my earlier post and I told you wrong about the connections to the PIC!! :o For final and for real, this is the way it should be, which is the way you now have it:

Max232 PIC
11 (T1in) 17 (TX)
12 (R1out) 18 (RX)
I'm just posting it here again for reference. Boy, how confusing. I'm sorry about that. At any rate I think all the hardware issues are now resolved.



So if this delay is increased then it would give more chance for the software to check for the PIC. Exactly.


Now, as to why your chip can only be programmed by the Bootlaoder once. It does tell us something that your program makes it successfully on the chip, and subsequently works. Actually this pretty much narrows the problem down to one thing.

Your joystick program, and all PIC programs, have an instruction, usually at the very beginning of the code space, that says "goto Main." This means that the first thing the PIC does when it boots is go to the "Main" routine, which is where your user code is. However, the Bootloader doesn't want it to do this. It wants the first thing to be that the PIC runs the Bootloader. So the Bootloader is supposed to re-locate your "goto Main" command somewhere else, and instead, it makes itself the first thing to get executed. Then when the Bootloader is finished with its thing, that's when it tells the PIC to goto Main.

What must be happening is that this process isn't working correctly. Perhaps the Bootloader re-located the directive to the wrong spot, or failed to re-located it at all, I don't know. The result is that when the PIC starts up, it goes straight to your code, rather than running the Bootloader first. This isn't the way it's supposed to work.

The Bootloader does require that your program have a "goto Main" command in the first four bytes of code space, but I looked at your joystick project and it appears that it does. But I'll look at it a bit closer this evening. I'm sure that's where the problem lies. We can probably just make a small tweak in the joystick code to get it to work.

More to come,


Luke

[LukeZ]

Malc,

Try this. In your rcjoy.asm file, replace this code near the top:

STARTUP code 0x0000

goto Main ; Reset vector
nop
nop
goto ISR ; High-priority interrupt vector trap
nop
nop
nop
nop
nop
nop
goto $ ; Low-priority interrupt vector trap


With this instead:

;----------------------------------------------------------------------------
;This code executes when a reset occurs.

ORG 0x0000 ;place code at reset vector
goto Main
nop
nop



;----------------------------------------------------------------------------
;This code executes when a high priority interrupt occurs.

ORG 0x0008
goto ISR


;----------------------------------------------------------------------------
;This code executes when a low priority interrupt occurs.

ORG 0x0018
goto $



You might try just flashing that code on the PIC without using the Bootloader. Then see if it even works. If it does, then try the Bootloader, and see if it makes a difference as to whether you can program it multiple times.


Luke

[Malc C]

Luke,

I'll give it a try in the morning (UK time) as I've got so many versions of the rcyoy program I'm not 100% sure which is what and need to create a new project. The file I thought worked fine (the one I was using earlier) seemed to compile OK with the changes you suggested, and windows shows the joystick under control pannel, but I had no movement of the axis. This was a problem I found when we were changing the code.. so I'm not 100% certain its down to your modification. I'm also knackered so can't think straight !

I still think its something to do with the flakey tiny bootloader software and the way it communicates. I erased the chip and loaded just the boot loader HEX - I clicked on the test pic button and gots some hits and some errors, - sometines unplugging the comms lead and re-connecting worked when the PIC was reset. here's a listing

Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------

Could not connect to COM1
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...

Could not connect to COM1
ERROR!
pic sending unknown data:Communication error 9994: Instance not yet connected
Check baudrate & Start Write while PIC is not sending serial data (e.g. in reset)
ERROR!

Connect COM1: ok
Searching for PIC ...

Could not connect to COM1
ERROR!
pic sending unknown data:Communication error 9994: Instance not yet connected
Check baudrate & Start Write while PIC is not sending serial data (e.g. in reset)
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

[LukeZ]

Malc,

That's a good test to run, just programming the bootloader software and doing the "Check PIC." I'm concerned though that it only finds the PIC every now and then, rather than consistently. You could try increasing the Search Delay under the Options tab, I think the default is 5 seconds but you could increase it. We could also try increasing that number in the bootloader code that determines how long the PIC waits for a signal. I might look at that again to see what an appropriate value would be, but I don't think it will hurt whatever you put in there. From the comment on that line it looks like he calculated the 1-second delay with a 20 mHz crystal. In fact, even though you're only using a 4 mHz crystal, because you have a weird chip the internal oscillator frequency is actually 24 mHz. So it could be that at the default settings in the code the PIC is actually waiting for slightly less than 1 second.

At this point I'm beginning to run out of ideas. I should just pick up an 18F2550 and try it myself.

One other thing, which probably isn't the issue but wouldn't hurt to try, is to power the board from a 5v supply other than the USB port. This shouldn't make a difference but I don't know, maybe it's not a steady voltage or there are transients that interfere with the serial communication - unlikely but wouldn't hurt to check it out.


Luke

[Malc C]

Hi Luke,

OK - this is what I've done and as its now 1.45am here in the UK I'm giving up for the time being !

1) - created a new project and made a new asm file that contained Mr-RC-CAM s modified config settings - asm compiled without errors

2) - loaded this into the PIC via the programmer - hex loaded without errors

3) - placed this in the development PCB and connected the USB cable - Windows recognised it and control panel registered the joystick - TX connected and tested in FMS worked fine

4) - removed the PIC and placed it in the programmer. Edited the asm code to include the new code mentioned in your post (#55) - compiled OK

5) - loaded the resulting hex file into the PIC - no errors

6) - Installed PIC in the development PCB, connected the USB cable and windows detected the interface - opened control panel - plugged in the TX and tested - all working fine.

7) - removed the pic and placed it in the programmer - erased and loaded the bootloader HEX

8) - placed PIC in the development PCB - connected both USB and RS232 cables and launched the tiny bootloder application. Experienced the same problems in PIC not found.

Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
HEX: 12 min old, INHX32,18Fcode+cfg, total=4230 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:0.781 sec

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Eventually after resetting the PIC a few times, changing leads the PIC was detected.

9) - loaded the version of rcjoy that contained your extra code (in post 55) - see log in point 8

10) - upon completion of the joystic hex being loaded windows detected the interface - control panel showed the interface to be working fine

11) - clicking on the check pic button resulted in the same old "Not found, ERROR!"

12) - all efforts to reset the PIC and stop it running the interface HEX and trip back failed.


Luke,

I'm in two minds to continue with this project... I certainly feel that if I do and you stil l wish to assist me in resolving this, that we do so via e-mails rather than using up server space here - especially as most of this thread has been two way conversations between us both and no one else wants to step in !

Anyway, hope the above points help - its now gone 2am and I'm off to bed !

[LukeZ]

Well Malc, you're nothing if not thorough. I give you credit for your patience!

Your tests certainly indicate that, when connected, the Bootloader can successfully transfer your program over to the chip. It also shows that when it does, that program still works. The problem, I guess, is a flaky connection issue, as well as, it would seem, an issue with how the bootloader re-locates your code, such that once programed it no longer calls the bootloader routine on startup.

At this point I am plumb out of ideas. If anyone else with experience with bootloaders would chime in about now, I'd be very appreciative. Or if someone else had an 18F2550 laying around that they could test, and see if they could replicate this problem, that might also be useful.

I am getting ready to place another order at Digi-Key. I'll pick up a couple of these chips as I think I'd like to have a USB-enabled PIC for some other projects anyway. When they come in I'll experiment on this end and let you know if I have any different results.

Anyone else care to jump in with a suggestion?


Luke

[Mr.RC-CAM]

I'm currently shoe-horning the Tiny Bootloader into an existing project. I'll report back as soon as I resolve the problems. With luck, that will be in a few hours.

[LukeZ]

Some confidence! That's what we need. ;)

Another thing I had thought Malc might try, when he wakes up on the other side of the pond, would be to go back to the 20mHz crystal, since that's what the sample bootloader program was written for. I felt like we had correctly changed the config settings so that it should work for 4mHz, but the intermitent connectivity issues makes me wonder.

Well, if you find the problem that will be great. I have gotten this to work successfully with an 18F2620, and had very little trouble too, so I know it's possible.


Luke

[Mr.RC-CAM]

Sometimes difficult problems have simple answers. In this case, change this line:
#define first_address max_flash-200 ;100 words
to:
#define first_address max_flash-.200 ;100 words

This will fix the issue where the bootloader stops working after the first successful flash.

[LukeZ]

Hmm, that's interesting. Can you explain what's going on there? Is this a change necessary due to the 4mHz chip, or is it an error on the part of the author, something that needs to be modified for an 18F2550?

I'm using the line un-modified on my 18F2620 and I have no problems...


Luke

[Mr.RC-CAM]

In my version of MPLAB (V7.30) there appears to be a Radix problem. The max_flash value is expressed in hex in the define file, where as the author expects that the 200 value to be in decimal because of a directive in the source file. However, the 200 is treated as a hex value instead, which pushes the start of the loader into an area that is not known by the bootloader's PC app. So, during the reflash, the bootloader mangles its own code.

By placing a decimal in front of the 200 (.200), the assembler will force it to a decimal value.

The Tiny Bootloader is brilliant work. The one thing that I don't like is that if communications fail during a reflash, the bootloader will default to being non-functional. I had a couple of instances of timeouts (my PIC program is huge) which killed the bootloader. It would also be nice if the bootloader code could be relocated to a larger space; I have some features I would like to add, but can't since there is no more room in the 100 word allocated space.

By the way, in my PIC18F2620 app, the spbrgselect.inc file created the wrong macro code for the UART's initialization. The loader's baud rate was half what it should have been. When I omitted the nifty macro code they provide, and hand coded it, it worked as expected.

[LukeZ]

Well I'm hitting the sack for tonight but tomorrow I'm going to look into what you say. I'm using a 20mHz 18F2620 and I didn't change either the max_flash line or the baud-rate generator macro. I seem to be able to connect without problems at 115200 baud. Like you I'm also using MPLAB 7.30. But I don't doubt you're correct and I'm going to look into my code a bit more tomorrow.

It's discouraging to hear that on failure the bootloader toasts. This is pretty bad news since I've just developed a board without ICSP. My plan is to flash the bootloader onto the chip, solder it to the board, and then do all further updates through the serial port. Since I'm still developing the code for this project I'm going to be doing lots of updates, increasing the chance for a failure during re-flash. If that happens I'm either going to have to take the chip off the board, or else solder on some ICSP header. It's an SMT PIC too, so that's a bit difficult to do.

Well, it's good to know anyways.


Luke

[Malc C]

It's discouraging to hear that on failure the bootloader toasts. This is pretty bad news since I've just developed a board without ICSP. My plan is to flash the bootloader onto the chip, solder it to the board, and then do all further updates through the serial port. Since I'm still developing the code for this project I'm going to be doing lots of updates, increasing the chance for a failure during re-flash.

Luke

That's exactly the way I was hoping to work, especially given the issues I had / have with ICSP when using the 18F2550.

A lot of what you guys have mentioned is way over my head (you guys could be talking Vulcan for all I know :) ) - But if I understand RC-Cam's post, modifying the bootloader code by placing a decimal in front of the 200 (.200) in the line stated should work.

I'll give that a go and get back to you.

Oh and I'm using MPLAB 7.31 so I'll let you know if it falls over with the same issues RC-Cam experenced.

Luke, I did get your e-mail, but I think given the fact we have one of the PIC Guru's joining in now, we might as well continue this thread as it may be of benefit to some others too. Right, I'm of to do a bit more testing and I'll let you know what the outcome is later

[Malc C]

Well the code with the small change RC-Cam mentioned compiled OK and the hex was loaded to the PIC. The PIC was placed in the development board and after a false start the PIC communicated with the PC. I then tried uploading the interface code and rather than squirting the code to the pic in less than a second the thing sat there for a long while and then reported an error (see the log below)

Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
HEX: 10 hours old, INHX32,18Fcode+cfg, total=4230 bytes.
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
HEX: 10 hours old, INHX32,18Fcode+cfg, total=4230 bytes.
Searching for PIC ...
Found:18F 2550/4550
Could not write
ERROR!

Connect COM1: ok
HEX: 10 hours old, INHX32,18Fcode+cfg, total=4230 bytes.
Searching for PIC ...
Found:18F 2550/4550
Could not write


I did notice that when you change the 200 to .200 (ie insert the decimal point) in MPLAB, the 200 is originally in black, but changes to match the same mauve text as the "first_address max_flash" before it.

EDIT:

Uhmmm.. I just went back to the bootloader after writing this post and clicked on flash pic...

Connect COM1: ok
HEX: 10 hours old, INHX32,18Fcode+cfg, total=4230 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:0.781 sec


Something is really flakey in this software ???

FURTHER UPDATE:

Well having loaded the interface HEX via the bootloader I tried resetting the PIC (switch between MCLR and +5v, or disconnecting the supply and re-connecting it) to access the bootloader - still no joy !



Connect COM1: ok
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...Not found,
ERROR!



Back to you guys !

[Malc C]

Ok here is some more feedback for you guys.

When I load the interface program via the bootloader, windows reports that there is a problem with the USB device and the joystic is not seen in game controllers. (burning the same interface code direct to the PIC via the JDM programmer works fine) This only occurs when I use the bootlader hex file generated from the asm file containing RC-Cams suggestion of changing the 200 to .200 I assume there were no other changes I needed to make ??

There also still seems to be some issues with the comms between the PC and PIC, so I can't hand on heart state that the issues are caused by the modifications to the bootloader asm, or by corruption during the transmission ?

Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

Connect COM1: ok
HEX: 11 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
Could not write
ERROR!

Connect COM1: ok
HEX: 11 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:0.781 sec


The other possible cause could be the hardware (although that seemed to check out OK) - or the PC (although the Mobo is a quality ABIT NF7) - However, if there was a problem with the comm port, I would be experiencing problems communicating with the PIC programmer too, and I'm not.

[xtal]

Here's a simple level translator I've used in the past on 16f84 pics...
It has worked quite well up to 19.2.....

The may be an issue with data inversion if used with uart?????????

[Malc C]

What's the value of the transistor ?

[Mr.RC-CAM]

It's discouraging to hear that on failure the bootloader toasts. This is pretty bad news since I've just developed a board without ICSP. I've tried to duplicate munching the bootloader but now I can't. No matter what I do, it survives all forms of comm interruption. So, I think that my concern was premature.

What's the value of the transistor ?In this circuit you don't need the transistor. In fact, using it will invert the RS-232 signal and cause other issues. BTW, you are using a MAX232 and it buffers the signal with very good fidelity.

This only occurs when I use the bootloader hex file generated from the asm file containing RC-Cams suggestion of changing the 200 to .200 I assume there were no other changes I needed to make ??MPLAB produces a list file with object code. This is the file that ends in ".lst". Can you please post the list file to the code with the 200 and the version with the .200?

[Malc C]

MPLAB produces a list file with object code. This is the file that ends in ".lst". Can you please post the list file to the code with the 200 and the version with the .200?

Hi,

I ran the quickbuild option and have attached the lst file (in txt format) one for the (dot)200 and one for (nodot)200. Hope they help ?

Malc

Oh and yes I am using a MAX232cpe chip to handle the coms between the PC and PIC

[Mr.RC-CAM]

Looks like you didn't have the problem I ran into. Both of yours files compiled the same and are correct, at least in regards to the Radix issue.

The next step would be to look at the hex images to see what is trashed. Post the following files (disable code protection if it is being used):
1) Joystick hex file. 1 file.
2) Bootloader hex file. 1 file.
3) Use the bootloader to flash the joystick code. Then, read the chip's contents using your chip programmer. Save it as "flashed_result.hex" and post the file. 1 file.

This will allow for some CSI work.

BTW, I suggest you use a slower baud rate until all the bugs are worked out. So, recompile the boot loader with this revised define: "baud EQU 38400"

[LukeZ]

I've tried to duplicate munching the bootloader but now I can't. No matter what I do, it survives all forms of comm interruption. So, I think that my concern was premature.Well that's good news to hear. It would be nice to pinpoint what the issue was you experienced, but in any case I'll hope it was a fluke.

In the instances yesterday when you had time-outs during programming, are these the types of timeouts that can be addressed by increasing the "Timeout" value on the Options tab? At one point in the documentation he states that the Timeout value is the ping interval when the PC is trying to establish a connection with the PIC, and that's all I thought it was for. But then later he also says - "Timeout" is the ping interval; also it acts as a timeout for all serial operations. If you expect large communication delays, you should increase this (but don't forget to also increase the timeout in tinybld)However I'm not sure if this gets to what you experienced or not. Timeout should be the amount of time that can pass between one byte of data being sent and the next - not the total time it takes for a program to download. There should be no limit on that, it seems to me. And perhaps there wasn't, if you aren't able to replicate it...


It would also be nice if the bootloader code could be relocated to a larger space; I have some features I would like to add, but can't since there is no more room in the 100 word allocated space.I'm obviously displaying my lack of knowledge, but this isn't something you can change simply by modifying the bootloader asm? This is something hardwired into the Windows interface?


Luke

[Malc C]

Hi,

As requested I changed the bootloader to 38400 baud, and recompiled

The HEX was then programmed into the PIC and the PIC placed in the development PCB. I launched the bootloader application and changed the transmission speed to 38400 baud and tested - it detected the PIC on the second try.

I then loaded the working joystick hex file via the bootloader. The first attempt failed (it sat waiting for 30 seconds or so before reporting it could not write to the PIC) - clicking on the flash PIC button a second time the transfer worked. - Upon completion Windows then reported that the USB device is not recognised etc...

I've attached a ZIP file containing:

Joystick working.HEX (this file works as a 4+6 joystick under game-controllers)
18F2550.HEX ( the bootloader hex file)
Recovered from PIC.HEX (the resulting hex file after transfer via the bootloader)

Hope this helps, if you want any further copies of files just let me know.

[Mr.RC-CAM]

In the instances yesterday when you had time-outs during programming, are these the types of timeouts that can be addressed by increasing the "Timeout" value on the Options tab?I was in the middle of resolving other bootloader issues, so there is no way for me to reconstruct the situation. At this point I feel my bootloader munching comment to be a false call.

There is a safeguard in the code to prevent writing to the Flash unless the CRC (Checksum) is valid for the block. So, a comm timeout should not ruin the bootloader kernel. The application may not run, but the bootloader should still be functional. However, the bootloader is a very small program and it, on its own, has limits to what it can protect against. The PC host is responsible for such things.

Timeout should be the amount of time that can pass between one byte of data being sent and the next - not the total time it takes for a program to download.That is correct. All actions related timeouts are on a ping'd transmit-receive, byte-by-byte, basis. The program can take as long as it needs to load (mine takes about 25 seconds @ 38.4K).

FWIW, increasing the timeout in the bootloader code {movlw (xtal/2000000)+1} actually made it less reliable for me. I thought this was a bit counter intuitive, but have not looked further into it.

I'm obviously displaying my lack of knowledge, but this isn't something you can change simply by modifying the bootloader asm? This is something hardwired into the Windows interface? The documentation is not very useful when it comes to this, so I suffered a couple of hours trying to figure out why relocating the bootloader causes bad things to happen. It turns out that the PC host software, which manages EVERYTHING, always requires that the bootloader code to be located exactly 100 words from the top of memory. If it is moved, the bootloader will become brain-dead after the first bootloaded app flash after it alters the redirected GOTO at address 0x0000. Too bad, since I really would like to add some features to the bootloader, but this limitation is in the way.

[Mr.RC-CAM]

I've attached a ZIP file containing:
Joystick working.HEX (this file works as a 4+6 joystick under game-controllers)
18F2550.HEX ( the bootloader hex file)
Recovered from PIC.HEX (the resulting hex file after transfer via the bootloader)That is helpful.

From what I can see, the "Recovered from PIC.hex" shows fully intact code from "Joystick working.hex" AND "18F2550.HEX." Furthermore, the address 0x0000 GOTO has been correct redirected, and the exit from the bootloader correctly branches to your joystick code. All of these things are all it takes. In other words, your flashed program should work.

Since it doesn't, then perhaps the bootloader has altered a PIC register or memory address that the joystick program assumes is still at a power up default. You'll need to look at the code to see if that sort of thing is going on.

For a simple test, take the PIC that you used bootloader to install the joystick (use the one that you read the "Recovered from PIC.HEX" from). Unplug the target's USB cable. With power off to the target board, click the "CheckPIC" button. Immediately (within two seconds) apply power to the target. Try this several times. Can you obtain a successful response?

[Malc C]

The documentation is not very useful when it comes to this, so I suffered a couple of hours trying to figure out why relocating the bootloader causes bad things to happen. It turns out that the PC host software, which manages EVERYTHING, always requires that the bootloader code to be located exactly 100 words from the top of memory. If it is moved, the bootloader will become brain-dead after the first bootloaded app flash after it alters the redirected GOTO at address 0x0000. Too bad, since I really would like to add some features to the bootloader, but this limitation is in the way.

Maybe an e-mail to Claudiu ( Claudiu.Chiculita@ugal.ro ) might help. He might be able to include some of the features in a new release ?

[LukeZ]

The documentation is not very useful when it comes to this, so I suffered a couple of hours trying to figure out why relocating the bootloader causes bad things to happen. It turns out that the PC host software, which manages EVERYTHING, always requires that the bootloader code to be located exactly 100 words from the top of memory. If it is moved, the bootloader will become brain-dead after the first bootloaded app flash after it alters the redirected GOTO at address 0x0000. Too bad, since I really would like to add some features to the bootloader, but this limitation is in the way.Yes, that is too bad. I understand the author's philosophy - make the program as small as possible to save on code space, and keep all the functionality on the PC side. This isn't bad so far as it goes... except that with the new 18 chips code space isn't nearly at the premium it used to be. And, although the PIC bootloader code is freely editable, the Windows app isn't. So although there's no longer the imperative to keep the code size so small, there also isn't a way to increase it.

I wonder how hard it would be to build on what he has and create an open-source bootloader. We'd just need to recreate the Windows application side of things, essentially. I build Windows apps for a living - but I rarely have cause to interface with external devices. I'm not sure how much effort it would be...

I also wonder how much effort it would be for the author to add an option to his existing application to allow the PC app to accept a larger bootloader code size - if that's all he would have to do. There may be more involved...


Luke

[Mr.RC-CAM]

I wonder how hard it would be to build on what he has and create an open-source bootloader. I believe he provide the source code to his DELHI coded app. I'm not a PASCAL kind of dude, so I'm not crazy about altering it. However, a customize PC applet would be very nice indeed.

Regarding the code relocation, I may contact the author. However, the empathetic side of me is resisting. I will assume his published free projects are like mine; That is, there is an endless number of incoming emails that request general help and customized firmware changes. I'm trying to not be another one of those endless emails to him (he can probably use the rest. :) )

[LukeZ]

Since it doesn't, then perhaps the bootloader has altered a PIC register or memory address that the joystick program assumes is still at a power up default. You'll need to look at the code to see if that sort of thing is going on.Here's something I'm not entirely clear on - in the bootloader assembly file, we specify CONFIG settings. Then, those settings are specified again in the actual joystick interface code. How does that work? Aren't the CONFIG settings set once, when the bootloader is flashed, and then aren't editable afterwards?

Luke

[Mr.RC-CAM]

Aren't the CONFIG settings set once, when the bootloader is flashed, and then aren't editable afterwards? Good point! The config settings used by the target app code will alter those previously set by the bootloader. So, the config settings related to the oscillator must match in both code sets. I doubt they do now.

[Malc C]

For a simple test, take the PIC that you used bootloader to install the joystick (use the one that you read the "Recovered from PIC.HEX" from). Unplug the target's USB cable. With power off to the target board, click the "CheckPIC" button. Immediately (within two seconds) apply power to the target. Try this several times. Can you obtain a successful response?

Uhmmm.. that's really interesting.

Having programmed the PIC via the bootloader windows reported a problem with the USB device. But, disconnecting the USB and the serial cable then plugging the USB cable back in the interface code ran fine and no errors were reported.

Then tried the above suggestion:

Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------

Connect COM1: ok
Searching for PIC ...
Found:18F 2550/4550

So it would seem that if you catch it quick enough, you can detect the PIC. However, all attempts to re-load the joystick working hex failed.

Connect COM1: ok
HEX: 19 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
Could not write
ERROR!

Connect COM1: ok
HEX: 19 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
HEX: 19 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
Could not write
ERROR!

So to my untrained eye it would seem that although the pc application detects the presence of the PIC, it fails to run the loader, or it runs but detects that there is already another program loaded at the start address and executes that ? Obviously for our intened purpose of sending regular updates to the PIC, this still appears to be a problem

[Malc C]

Config settings from the joystick asm file


CONFIG PLLDIV=1, CPUDIV=OSC3_PLL4, USBDIV=2
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
CONFIG PWRT=OFF, BOR=ON, BORV=3, VREGEN=ON
CONFIG WDT=OFF, WDTPS=32768
CONFIG MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=ON
CONFIG STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF ; ICPRT=OFF,
CONFIG CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
CONFIG WRT0=OFF, WRT1=OFF, WRT2=OFF
CONFIG WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR0=OFF, EBTR1=OFF, EBTR2=OFF
CONFIG EBTRB=OFF
IFDEF __18F2550
CONFIG WRT3=OFF, EBTR3=OFF
ENDIF


and from the bootloader


CONFIG PLLDIV=1, CPUDIV=OSC3_PLL4, USBDIV=2
CONFIG FOSC=XTPLL_XT, FCMEM=OFF, IESO=OFF
CONFIG PWRT=OFF, BOR=ON, BORV=3, VREGEN=ON
CONFIG WDT=OFF, WDTPS=32768
CONFIG MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=ON
CONFIG STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF ; ICPRT=OFF
CONFIG CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
CONFIG WRT0=OFF, WRT1=OFF, WRT2=OFF
CONFIG WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR0=OFF, EBTR1=OFF, EBTR2=OFF
CONFIG EBTRB=OFF
IFDEF __18F2550
CONFIG WRT3=OFF, EBTR3=OFF, CP3=OFF
ENDIF


I've used the same config settings.....

[Mr.RC-CAM]

The OSC settings are the same. In both files, change the following config fuse settings to:
STVREN=OFF
PWRT=ON
These changes are just for good measure.

At this point, I understand you can flash the USB code with the bootloader and it works. However, it seems that the bootloader is correctly detected, but fails to write the app code if you attempt another flash. If that is true, then you have come a long ways. :)

There is a "logdetails" function in the applet. Try it and see if it reports more info about the write failure.

[LukeZ]

This may be a problem to fix last, or it could be part and parcel of the overall issue - but I'm still a bit confused as to why you can't connect to the PIC on a consistent basis. Either you're really slow in getting the power applied ;) or else there's something else going on. When I try to connect to my PIC I can get it to go one hundred times out of one hundred. Ok, that's an exaggeration, I haven't actually tried it that many times - but I do get consistent connections.

I don't want to confuse the direction of troubleshooting we're taking here. But maybe at some point it would still be useful to see if the consistency changes at all with a switch to the 20mHz crystal (or any different crystal).


Luke

[Mr.RC-CAM]

But, disconnecting the USB and the serial cable then plugging the USB cable back in the interface code ran fine and no errors were reported.Maybe it is time to change the BOR voltage. Set the config fuse in both files to "BORV=1"

This may be a problem to fix last, or it could be part and parcel of the overall issue - but I'm still a bit confused as to why you can't connect to the PIC on a consistent basis.Not to confuse things even more, but when all I have loaded is the bare bootloader, my CheckPIC success rate is probably 60%. But, I have 100% success in flashing the app code once it has been loaded once. The trick is to be quick with applying the power after pressing the WriteFlash button.

... maybe at some point it would still be useful to see if the consistency changes at all with a switch to the 20mHz crystal (or any different crystal)What xtal is being used? Is it a parallel or series type. Accuracy will vary if it is series.

Also, when the bootloader is compiled, are there any reported warnings about baud rate accuracy? The bootloader source code macros do a simple baud clock accuracy math test during compile and will report issues if it finds one. Any error beyond 3% is subject to comm trouble. So, check the compiler's report.

Lastly, if there is a basic communication issue, like an off-tune Osc, then the logdetails reporting should show the communication retries. Or so I would think.

[Malc C]

Hey guys, check this out !


Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:1.657 sec

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:1.657 sec

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:1.656 sec

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...
Found:18F 2550/4550
WRITE OK. time:1.656 sec


OK it might not be Lukes 100 out of 100, but it seems to be working - I have to set the application polling the PIC first and then connect the power (using a switch to take MCLR to +ve doesn't work). I have no real idea as to why it just started working, I've left it running on the desk since my last post, had a drink, came back and tried flashing the PIC a few times to answer your questions... and hey 4/4 :) - you watch it will stop working later !

[LukeZ]

The trick is to be quick with applying the power after pressing the WriteFlash button.Seems to me like this could easily be fixed by increasing the Search Delay value on the "Options" tab, no?



Also, when the bootloader is compiled, are there any reported warnings about baud rate accuracy? The bootloader source code macros do a simple baud clock accuracy math test during compile and will report issues if it finds one. Any error beyond 3% is subject to comm trouble. So, check the compiler's report.Unless, as you noted earlier, the macro incorrectly calculates the baud rate generator bits. I haven't had time to examine this, but would the error you encountered cause the macro to not submit a warning message when in fact one was called for?



I have no real idea as to why it just started working, I've left it running on the desk since my last post, had a drink, came back and tried flashing the PIC a few times to answer your questions... and hey 4/4What kind of drink was it? ;) I'm betting that was it... :)


Luke

[Malc C]

Edit that.. I tried again

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...Not found,
ERROR!

Connect COM1: ok
HEX: 20 hours old, INHX32,18Fcode+cfg, total=4242 bytes.
Searching for PIC ...Not found,
ERROR!

To try and answer some of the points raised (you guys are posting really quick !)

What xtal is being used?
I'm using a 4Mhz resonator with a pair of 22pf disc ceramics.

Also, when the bootloader is compiled, are there any reported warnings about baud rate accuracy? The bootloader source code macros do a simple baud clock accuracy math test during compile and will report issues if it finds one. Any error beyond 3% is subject to comm trouble. So, check the compiler's report.

There are no errors when compiling the bootloader - here is the output report


Clean: Deleting intermediary and output files.
Clean: Deleted file "C:\18F2550.mcs".
Clean: Done.
Executing: "C:\Program Files\Microchip\MPASM Suite\MPAsmWin.exe" /q /p18F2550 "18F2550.asm" /l"18F2550.lst" /e"18F2550.err"
Loaded C:\18F2550.COD.
BUILD SUCCEEDED: Fri Apr 07 22:14:46 2006

At this point, I understand you can flash the USB code with the bootloader and it works. However, it seems that the bootloader is correctly detected, but fails to write the app code if you attempt another flash. If that is true, then you have come a long ways.

Compared to how things were, we've (I've) made a huge leap forward. - Thanks guys

[Mr.RC-CAM]

Seems to me like this could easily be fixed by increasing the Search Delay value on the "Options" tab, no?Sure can. The side affect of long delays is that you have to wait longer, before retrying, when the communications are not working. For me, a 3-sec delay is perfect.

I'm using a 4Mhz resonator with a pair of 22pf disc ceramics.Resonators are not as precise as an xtal (the data sheet will offer full details). Until you obtain reliable operation, I suggest you switch to a compatible 4Mhz xtal.

In the meantime, turn on the logdetails feature. It will give you detailed reports on each code block flash transaction. I would be interested in knowing if it reports any CRC errors or retrys during a successful flash.

Also, try changing the fuse settings I mentioned earlier.

[Malc C]

Seems to me like this could easily be fixed by increasing the Search Delay value on the "Options" tab, no?
Luke


Didn't work for me :mad:

Just been looking at the bootloader code and wondered what these comments mean and if they had any impact on these issues

;************************************************* ************
; After reset
; Do not expect the memory to be zero,
; Do not expect registers to be initialised like in catalog.

END

Anyway guys, after a 2.30am turn in yesterday (this morning :confused: ) I'm off for an early night - nite !

[Mr.RC-CAM]

Just been looking at the bootloader code and wondered what these comments mean and if they had any impact on these issues.It is a cautionary notice that you should not trust any ram or register value after the bootloader runs. However, at this point your problem is only with the bootloader on a fresh reset. So the memory and register values will be known (and trustworthy) and are not the immediate issue.

If you had problems with the bootloaded app code, then this would require more investigation, per my earlier comment.

[Malc C]

Resonators are not as precise as an xtal (the data sheet will offer full details). Until you obtain reliable operation, I suggest you switch to a compatible 4Mhz xtal.

OK I'll get a 4 Mhz xtal and try that - possibly won't be until Monday

In the meantime, turn on the logdetails feature. It will give you detailed reports on each code block flash transaction. I would be interested in knowing if it reports any CRC errors or retrys during a successful flash.

Also, try changing the fuse settings I mentioned earlier.

Ok I'll try the fuse settings in the morning, are the options mention "logdetails" in MPLAB or the bootlader application (can't find it in the bootloader so I assume its MPLAB ??)

[LukeZ]

Malc, to turn on the logdetails option in Tiny Bootloader, just type "logdetails" in the main window. It will append an "ok" after it. Then, whenever you take an action it will show you more info than before.


Luke

[Mr.RC-CAM]

I'm using a 4Mhz resonator with a pair of 22pf disc ceramics.FWIW, if it is a 3-terminal resonator, then it may already have the two caps inside it (the center pin would be ground). Adding external caps would not be a good thing if it already has them. Do you have a data sheet to the part?

But, for now, get some rest. Don't let the software bugs byte!

[Malc C]

Morning guys

OK i've typed logdetails into the tingbootloader and this is what I got on five attempts to connect with the PIC that had been flashed with the joystick code (I use RC cams method of click on check pic and then plug in the power) Hope the info helps



Interface to TinyBootLoader, v1.9.1
contact: claudiu.chiculita@ugal.ro
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
--------------------------------------------------------------------------------------------------
logdetails ok,

Connect COM1: ok
Searching for PIC ...
Wait 600 ms
Wait 600 ms
Wait 600 ms
Wait 600 ms
Wait 600 ms
Wait 600 msNot found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Wait 600 ms
Wait 600 ms
Rcv:type=55h=U
K found
Found:18F 2550/4550


Connect COM1: ok
Searching for PIC ...
Wait 600 ms
Rcv:type=FFh=ÿ Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Wait 600 ms
Rcv:type=FFh=ÿ Not found,
ERROR!

Connect COM1: ok
Searching for PIC ...
Wait 600 ms
Wait 600 ms
Rcv:type=FFh=ÿ Not found,
ERROR!


The resonator I'm using doesn't have internal caps, hence the use of 2 x 22pF disc ceramics - I have no data sheet.

[Mr.RC-CAM]

I am interested in the logdetails report when you successfully boot flash the joystick code.

Have you altered the fuses?

[Malc C]

I am interested in the logdetails report when you successfully boot flash the joystick code.

Have you altered the fuses?

Ok I quicky did the following before going out for the evening (rare event in our house !)

Made the chages to the config settings as you suggested.

STVREN=OFF
PWRT=ON

I did this in both the bootloader asm and the joystick asm to be on the safe side. Compiled both

Erased the PIC and burnt the bootloader to the PIC. Placed the PIC in the development board and loaded the tinybootloader application. Flashed the PIC.

Then re-flashed the PIC a total of three times (with the odd - PIC not found error as I had to use the old method of polling the PIC and powering up the PCB and obviously not quick enough :) )

I've attached the log details as a txt file due to the length - Hope it helps

[Mr.RC-CAM]

Then re-flashed the PIC a total of three times (with the odd - PIC not found error as I had to use the old method of polling the PIC and powering up the PCB and obviously not quick enough )I see three boot flashes. The second one required three attempts by you to get it to finally connect. The other two boot flashes seem to have been problem free. Is this what you mean? If not, can you elaborate?

The log files show no comm errors on any of the data packets. If there was a subtle baud rate accuracy issue, I would have expected some packets to need resending. Overall, I don't really see anything that would indicate you should have a problem.

What it is the current state of the bootloader, as far as overall operation goes?