Post by thread:More MPLAB gotcha's

For many hours I've been chasing a problem with a boot loader jump vector being overwritten. It turns out that MPLAB 5.70.40 writes this record to location 0000 REGARDLESS of what the source file contains. e.g. :020000040000FA :00000001FF The source file is down to NOTHING! ;================ END ;================ What's up with this nop record, regardless of code?? I'm in 'simulate' mode for a 16F876, which is how I've always run before I was STUPID enough to overwrite my old 5.10 version. Any suggestions on how to fix this so I don't have edit the hex file every time I want to use the bootloader? Robert -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Maybe INHX8M mode, not INHX32. regards Tony Robert Rolf wrote: {Quote hidden}> > For many hours I've been chasing a problem with a boot > loader jump vector being overwritten. > It turns out that MPLAB 5.70.40 writes this record to location 0000 REGARDLESS > of what the source file contains. e.g. > > :020000040000FA > :00000001FF > > The source file is down to NOTHING! > ;================ > END > ;================ > > What's up with this nop record, regardless of code?? > I'm in 'simulate' mode for a 16F876, which is how I've always run before > I was STUPID enough to overwrite my old 5.10 version. > Any suggestions on how to fix this so I don't have edit the hex > file every time I want to use the bootloader? > > Robert > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>Robert Rolf wrote: >> >> :020000040000FA >> :00000001FF >> >> What's up with this nop record, regardless of code?? >Maybe INHX8M mode, not INHX32. >regards >Tony The last record is not a nop, it's an end of file, because it has a type of 01. Oh, you meant the other one :-) That one has a type of 04 which means it's not a data record, but an "extended address record". This is to account for 32 bit addresses; in your case it just says the upper address bits (think 'banking') are zero. So your recourse is to ignore (or interpret) that record. Been there, wrote a bootloader, had the same problem. And as Tony says, this is an extension added for hex-32. And maybe the hex-8 format won't have anything like this. It should be happy on a 14-bit part, anyway. Barry -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Barry Gershenfeld wrote: > >Robert Rolf wrote: > >> > >> :020000040000FA > >> :00000001FF > >> > >> What's up with this nop record, regardless of code?? > > >Maybe INHX8M mode, not INHX32. Dunno. No option appears to exist to set HEX file format in MPLAB 5.** > >regards > >Tony > > The last record is not a nop, it's an end of file, because > it has a type of 01. Yes, I recognized that, but wanted to put my complaint into context. > Oh, you meant the other one :-) That one has a type of 04 > which means it's not a data record, but an "extended address > record". This is to account for 32 bit addresses; in your > case it just says the upper address bits (think 'banking') > are zero. So your recourse is to ignore (or interpret) > that record. Been there, wrote a bootloader, had the same > problem. And as Tony says, this is an extension added > for hex-32. And maybe the hex-8 format won't have anything > like this. It should be happy on a 14-bit part, anyway. The interesting thing is that I am using Tony's bootloader, and it worked fine until I upgraded to MPLAB 5.70.* The old files start with line two below. The new ones with line one. (reformatted to make the fields more obvious). Just one more unexpected and undocumented 'feature' of an MPLAB upgrade. 1:02 0000 04 0000FA ;of what value is this record, if it has no content? 2:0A 0006 00 2328F100030E8301F2002D ;data at address 0003 (since it's 14 bit) 3:10 0010 00 0A08F4000408F3000A308A008617002A50 ;etc... Unfortunately Tony doesn't yet have an upgrade to ROMZAP that ignores extraneous record types. Thanks for the comments. Robert -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Robert Rolf wrote: > Unfortunately Tony doesn't yet have an upgrade to ROMZAP that ignores > extraneous record types. Thats probably the key. ROMzap only works with INHX8M files not INHX32. It never crossed my mind back then to use INHX32. (pre 18F ???) regards Tony -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics