Stuck in bootloader (shorted trace)

[dinomight]

Ok so i've been using the irtoy for a while now, and i've flashed it several times without issue (initiated from software, and also using the PGC and PGD method and both methods appear to work, flashed seem great)

Code: Select all

c:\Users\dylan.DARKSPARQ\Downloads\IRToy-v23-test1>fw_update -e -w -v -m flash -vid 0x04D8 -pid 0xFD0B -ix USBIRToy.v2
U2IO flash erasing: DONE.
U2IO flash programming: DONE.
U2IO flash verifying: DONE.
RESET Device
Operation successfully completed.

Now however it's stuck in bootloader mode. I'm able to connect via fw_update,I have also confirmed that it returns a2.0 version of fw_update, and 0.2.2 bootloader version).

Code: Select all

c:\Users\dylan.DARKSPARQ\Downloads\IRToy-v23-test1>fw_update.exe -ver -vid 0x04D8 -pid 0xFD0B
fw_update Version: 0.2.0
U2IO BootLoader Version reading: DONE.
BootLoader Version: 0.2.2

I've tried several different firmware version, i've tried using the bat/shell scripts as well as running the commands manually. I've even tried on both linux and windows. No matter what method i tried, it just won't leave bootloader mode.

i wanted to check to make sure there wasn't short between pgc and pgd..... Nope....

i did notice something odd. PGC is shorted to ground... Based on the schematic it doesn't look like it should be the case. I'm starting to think that this might be what is keeping it in bootloader mode. I'm almost ready to unsolder the PGC pin on the chip. doesn't look like i'll use the iscp pin other than connecting pgc and pgd for bootloader programming
Any thoughts?

[dinomight]

Ok so it pulled the pins...... No go. the pins on the IC have been pulled up. they are not touching the board.... funny thing.... the PGC pin (27) is still pulled to ground. so the pin is grounded in chip. At this point
1. not bridging pgd pgc,
2. pgd and pgd are not connected to any trace on the board, ie pins are pulled up until they dont touch anything.
3, pgc pin is connected to ground.

I can only assume that in software it is set to ground, or there is a hardware failure. according to the schematic they should not be connected (unless bootloader mode is desired.)

It should be noted that the chip works while in this bootloader state. I can read, write, reset, get version, all being displayed with positive results. I can enumerate the device in windows and linux. I've tried every version of the ir firmware (USBIRToy.vXX.hex)

Everything is working, it just won't leave bootloader mode.

I'm out of theories. does anyone have something else i can try or poll?

[dinomight]

Well i think i'm S.O.L. i've tried all that i can think of, and i'm not getting out of bootloader. Unless anyone has any ideas i'll just have to buy a replacement.... too bad they are out of stock. crrraaaappp i sat down tonight hoping to work on a projeect, only to be reminded that mine was busted. (and now i have to not only wait for shipping, but also restocking)
:-( can someone please hlep me fix this stupid thing.

[ian]

I'm sorry about the problems with the board. The PGC and PGD pins are manipulated in a pattern to test if a jumper is present, but beyond that brief period should always be floating. A pin grounded permanently or pulled high permanently should always result in user mode and not bootloader mode.

I notice you use "-m flash", which only erases main chip. Maybe resetting EEPROM contents will help? You can replace it with "-m flash". To test: short the PGC and PGD you pulled up from the board and try this command line:

Code: Select all

fw_update -e -w -v -m all -vid 0x04D8 -pid 0xFD0B -ix USBIRToy.v2

[dinomight]

THanks for the sugesstion.... last night i already had gone though it all. i wrote, and then read and then manually confirmed that they were being flashed correctly, i did this with multiple firmwares. All succesfully wrote and verified. I tried erasing the eeprom.

I went so much as to look at the bootloader source documentation, and i found out how BL mode works.
if the first bits are set to 5A when the the chip starts it will enter bootloader.

this if from the bootloader source config.

Code: Select all

; EEPROM Mark to run bootloader
#define USE_EEPROM_MARK      1   ; Enable EEPROM MARK. To disable = 0
#define EEPROM_MARK_ADDR   0x00   ; EEPROM Address for MARK
#define EEPROM_MARK      0x5A   ; MARK value


the important this here is if 0x00 = 0x5A then goto bootloader, anything other value and the chip goes to the user program.
When i check the eeprom i do in fact have it set to 0x5A, a reset is supposed to clear that byte. it wasn't working so i manually set it to 0x00, then read out the eeprom again and it had been changed. so reset and i should be good.nope... it boots up, enters into bootloader and then i check the eeprom only to find that the byte has reverted back to 0x5A, same thing if reset using fw_update ... something is resetting it. I also found another interesting bit in the io_cfg,inc

Code: Select all

;-----------------------------------------------------------------------------
; Jumpers
#define USE_JP_BOOTLOADER_EN   1   ; Undef/comment if you not want to use FW Jumper
#ifdef   USE_JP_BOOTLOADER_EN
#define JP_BOOTLOADER_TRIS   TRISB
#define JP_BOOTLOADER_PORT   PORTB
#define JP_BOOTLOADER_LAT   LATB
#define JP_BOOTLOADER_PIN   6   
#define JP_BOOTLOADER_PULLUP INTCON2
#define JP_BOOTLOADER_PULLUP_BIT   7
#endif


this defines the "force bootloader" is on port B: B6 and B7. this is pins 27(pb6/pgc) and 28(pb7/pgd). This supports the irtoy documention.

At this point i'm really getting stumped. read/write/erase/verify flash, read/write/erase/verify eeprom all work. The 0x5a can be changed, but after either a reset or disconnection/reconnection the eeprom reverts to bootloader, and resets to 0x5a
Something is changing it, but what:?

[dinomight]

so i tried a whole heck of a lot of stuff, using more and more of the bootloader documentation found on diolan's site..... I finally found something

From: http://www.diolan.com/pic/bootloader_doc/jumper_configuration.html

Jumper is used for hardware entry into the programming mode. It connects the corresponding microcontroller pin to ground (GND). To enter the programming mode close the jumper at the moment of device connection to USB. During initialization bootloader checks the value at the corresponding pin. If value is equal to zero, bootloader enters the programming mode.

ss
Bamm!!
the juper must be high.... floating won't cut it, especially since my jumber pin was shorted to ground. so i hooked up the pin (27) to 5V, and write, and reset, and we are out of bootloader mode and in to application mode...... YAY.... now since it is getting hot lets replace the wire with a resistor. ......
AND.......
Dumb roll please ......
I broke the foot of the chip off, Since i had lifted the feet of the jumpers (27,28), the wire used was was too thick , solid core it just snapped off.i think i'm boned.
i even figured it out..... this sucks, find the problem only to break it at the last moment....

So my options now are to try to grab what little copper is exposed on the side of the chip, or if at all possible reflash bootloader on the chip. I can recompile it to use another pin for jumper or disable the jumper pins altogether.

I don't have a usb pic programmer, let alone a pic programmer. (plenty of atmel stuff just no pic). Is it at all possible to flash the bootloader in software. It's stuck in BL mode so i though i might have a slight chance but i'm very doubtful.

Anyone have any final suggestions. pull pin 26 high, or recompile and reflash the bootloader.... sooooo close, and then sooooo far away.

[Sleepwalker3]

Where abouts are you? I'm guessing the other side of the rock, but if you happen to be downunder, I might be able to help with a programmer, swap the chip or do the resoldering of the pin.

I'd probably just remove the chip and replace it, but if I was stuck where I couldn't get a replacement or whatever, I'd use a tiny burr (say a 0.5mm dremmel burr) on a high speed tool (eg. a small dremel) and just grind a tiny bit of the plastic away, then use a good flux to tin the little exposed part of the chip leg, then use a fine wire (eg. a strand from a bit of mains cable) as a jumper to the pad. If you do that successfully, then I'd suggest carefully securing the wire with a bit of hot melt glue or something, so you don't accidentally bump it later.

I've used this method a number of times before and if it's done properly, it will last for the life of the device.

You could also try a conductive varnish like circuit works pen or go to the Auto store and buy some of the stuff they use to repair rear window demisters, it's usually cheaper than a circuit works pen.

[dinomight]

thanks for the tip... i'll try to pull back some of the ceramic. After some work last night with inconsistant connection to power i found that vcc->27 might not properly fix the problem. It might solve the problem to begin with (sometimes) but i think constant power is a problem as the chip acts kinda wonky. (and draws way to much current) it if remains connected after booting. it's kind of like it should be high on start and then floating/grounded on application run. I'll look at the bootloader even closer and see if i can figure it out. after several attempts and tons of flux/solder i got a 27 connected to a wire, the heat however may have overheated/killed the chip. I can still read/write/verify/erase. so maybe it's not all lost.

From what i can tell about the diolan bootloader, it is programmed so that it can't be programmed or read, this is as part of the encryption the chip supports (the chip can actually encrypt your code.... kinda cool). I think this rules out reinstalling a modified bootloader.

So i'm going to go back, look more into the bootloader, and fix/use that broken pin.

[dinomight]

Ok so this has been a learnding experience... I've been reading through the bootloader code. The bootloader was modifed for the usbirtoy.... but reconfigured is a little more accurate. So the boot loader in the IRToy does this.... if i read it correctly.
As it boots it first pulls 27 high using an internal pullup

Code: Select all

#define JP_BOOTLOADER_PULLUP INTCON2

Code: Select all

   ; Check bootloader enable jumper
#ifdef USE_JP_BOOTLOADER_EN
   clrf   JP_BOOTLOADER_PORT      ;PORTB low
   clrf   JP_BOOTLOADER_TRIS      ;TRISB output
bcf      JP_BOOTLOADER_PULLUP, JP_BOOTLOADER_PULLUP_BIT ;clear RBPU to enable B pullups
   bsf      JP_BOOTLOADER_LAT, JP_BOOTLOADER_PIN   ;PGD to input
   nop
   nop
   btfsc   JP_BOOTLOADER_PORT, JP_BOOTLOADER_PIN   ;skip app go to BL if bit is clear
   bra      cleanupandexit   ;disable and skip to user app
   bsf      JP_BOOTLOADER_PULLUP, JP_BOOTLOADER_PULLUP_BIT   ;turn PORTB pullups off
   setf   JP_BOOTLOADER_TRIS      ;trisB back input
#endif
   ; Run bootloader
   bra   bootloader
   reset

important line:

Code: Select all

   bcf      JP_BOOTLOADER_PULLUP, JP_BOOTLOADER_PULLUP_BIT ;clear RBPU to enable B pullups

y

So the chip boots, sets the BL pin to up via the internal INTCON2 and then checks to see if it pulled down (by pin 28 in particular). If pin 27 is gnd then it enters BL mode, assuming that it is connected to 28. otherwise it inters application mode. It then releases INTCON2, pin27 and pin28.

My current theory is that INTCON2 is stuck down, it it's grounded causing it 27 to be seen as jumpered to 28. That's why if i pullup the pin by connecting 27 to VCC on boot it will enter into app mode.

This would be great but i can't leave 27 high.... it's causing heat issues among other things. I need to find a way to fix INTCON2, a way to open 27 until after app boot. or burn a new bootloader... i'm getting a little hope of this based on this line in the config

Code: Select all

CONFIG  CPB = OFF            ; Boot Sect Code Protect

not sure how to access the Boot sect though. I'll check back in when progress is made.... If anyone understands stuff better than me chime in and correct my understanding

[ian]

This is a bum chip for sure, I'm sorry about that. Our self-test wouldn't have caught it, but I assume the EEPROM or another register is bad, or the shorted trace caused a problem on the pin.

Please contact Seeed for a replacement and reference this thread.

[dinomight]

seriously think Seeed would process a return on this unit. The part order is very old, I've pull up two traces, soldered wires to the chip, flux residue covers most of the board.and no real way to make it back to stock. It looks like shit, and is probably unfixable without some heavy modifications, hence this thread. So the solution is up to me.

EEPROM looks to be fine (write,verify works just fine)....

it has to be a problem with intcon2. it is the only thing that still connected to pgc/27/pb6.it is absolutely the only thing touching pin 27/pgc/pb6 (literally)

I've been trying to compile the firmware so that it pull the pullup/INTCON2 and holding the eeprom's bit programming bit(0x000->0x52) after starting. I'm hoping it allows the app bit to survive the reboot.

I'm not sure if it will work(very unlikely.) i think the bootloader pulls up 27(via intcon2) then checks the pgc/27->pgb/28 bridge, then checks for the eeprom bit.... If INTCON2 were broken then it would test true and it would always ignore the eeprom BL bit . I think that would make sense. you want the 27-28 to force it in to BL mode. I think i still need to find some way to intcon2's correct behavior.

if i can pull up 27, and then release after boot it would act properly.
Since i can't change anything in the BL there is no way to change the mapping of pgc/27 or intcon2. I need another solution
(perhap using s one of the io ports. Vcc->RB0 ->pgc/27/pdc, then from app pull GND->RB0->pgd/27. i think this would pull up via rb0 and in turn pgc/rb6/27 and then release it once the running.
I think that would emulate INTCON2 in parallel.

I spent some time last night trying to get the build env setup on my computer so that i could compile the firwares. Took a while but I just got it working before bed,(mplab-linux) so hopefully tonight can compile, then modify the default firmware to start changing the eeprom/intcon2/pb[0-5]. just need a way to get pgc/pb6 to start high then drop after app boot.

Well again i'll keep you up to date tonight when i make progress or learn more.

For me at least, This has been a very good experience getting in to hardware/firmware/asm code, and better understanding of this and other circuits. This thread has become very long, but i hope that someone at some point might, and benefit from all of my discoveries...

[Sleepwalker3]

Again, if it were me, I'd be changing the chip, but I'm assuming that's not practical for you (or you may want to find another solution and that's fair enough). I'm not entirely following (too tired, long day), but I think what you are saying (in very simple terms) is that you need to pull the pin high for a short period and then have it pulled low - is that correct?

Assuming for the moment that is that case, then it's pretty easy. ...of course if that's not what you're saying then I've just wasted my time writing all this stuff below!

Get a capacitor and wire it from the positive rail and hook the other end onto the pin you want pulled high at turn-on. Now hook a resistor onto the pin also and the other end of the resistor will go to 0V (what you might call ground or the negative rail, but should be called 0V). The size of the cap and resistor will determine how long the pin stays high. You'll need the resistor to be probably above 1k, though I don't know the timing you're looking for, so I'm just plucking figures out of the air. I'd probably start with 2k2 and work from there. The cap you probably want something around say 1uF and work your way up *if* needed. If using a ceramic, then you don't need to worry about polarity, if it's an electro or a tantalum, then you'll need to connect the + side to the Positive rail and the negative to the pin. Electros are almost always marked showing the negative pin, Tantalums are almost always marked showing the + pin.
If you have an oscilloscope then you can look at the charging and work your values from there, You can calculate the RC time constant, though if that pin is cactus there will be a low impedance to 'somewhere' and that will muck up the figures, so forget that and just play with caps and resistors till you get something that works - bigger caps and higher value resistors will make the RC time constant slower, so the pin will stay high longer. Better to keep the cap value fairly low and have a higher resistor value, but if you go over about 100k or so you're likely getting too high. If the cap is huge, it could create problems with stored charge taking the pin too far negative when power is turned off. You can connect a reverse biased diode across the resistor to prevent this, anode to the 0V rail, cathode to the pin junction, but it likely won't be needed if you keep the cap as low as practical.

One more tip - Flux can make your high frequency circuits (eg. your Crystal oscillator) play up and may do all sorts of odd things, so clean all that flux off with a flux remover spray, or Isopropyl alcohol (use stuff as close to 100% pure as you can get) and dry it, preferably before playing.

Hopefully that will help you.

[dinomight]

Thanks for quick reply. I'm very limitted in the tools i have here. I don't have a pic programmer anywhere. and as for an osciliscope,. it's out of reach for while. while new chip is a favorible solution for many people, right now isn't possible, and to be honest buying a new one seems cheaper and easier than rechipping.(yes i know that i've spent way more time than than rechipping.) So if/when they are available a new replacement will be my solution.

It's funny you suggested a Cap/resistor. It was actually one of my first thoughts... i abondoned it early on, well i actually forgot about it. as i delved into a maze of code. I seem to look for and try the most complicated method to solve a problem (a huge flaw of mine) . Still this has been fun, and i'm looking for the treasure chest that contains the horribly complex solution.

I think i'll put in the cap/res via header pins and the i can use it now (as i have an immediate requirement,) and can remove it at will, to keep trying an inchip solution.... fun fun fun.

Thanks for the help. also i'll get the flux off.

[Sleepwalker3]

Oh, and if that works, you owe me a beer :P

[Sleepwalker3]

Have you ever used chipquick? If you have a temperature controlled soldering station (or worst case even a plain iron) and a chipquick kit, you can undo the chip without fancy equipment.