PIC18F27Q43 - TMBL+ is not writing EEPROM or CONFIG bytes

[Brendan]

Hello,

I have some EEPROM data in my HEX file, as well as config bits. TMBL is not loading those bytes into EEPROM or CONFIG .... I don't think this is a problem on the firmware, as I don't even see TMBL trying to send these Bytes (even though "Write EEPROM" is checked).

Also, a check-box asking to write (or not) CONFIG bits would be helpful.

Thanks!

[Anobium]

We have totally rewritten the TBL auto tooling for the Q43. The issue may not exist in the new TBL code. Send me your HEX and let me test.

[Brendan]

Bootloader HEX attached. My concern is: I didn't even see the application (PC side) try to send config or EEPROM.

[Anobium]

I dont want the TBL. I am testing against our new TBL. Does have a the errant user hex?

---

We clear down the Buffer in our new Automated Tooling. So, we should not see an issue.

[Brendan]

Well, we're in a couple of different threads here ... this particular thread relates to the PC App not sending CONFIG or EEPROM in the download...But, attached is a HEX file you can test with...

[Brendan]

As you can see: That hex file has both CONFIG and EEPROM data ... (although, I'd love a way to choose whether CONFIG bits are written)

:020000040030CA
:0A000000FFFFFFFFFFFFFFFFFFFF00
:020000040038C2
:080000004527CABADDCABADDCA
:00000001FF

[Anobium]

We need Bill, but, config is NEVER written. As this would break things.

[Anobium]

You HEX loads into our TBL+ OK. I see no corruption.
There is something wrong with the location of your EE as this fails, but, when, the address is correct the EE is written.

[Brendan]

The address of the EEPROM is correct ... that HEX came straight from MPLABX ... and per the data-sheet, EEPROM on the Q43 is at 0x380000 (which is what's in the hex above). What did you change the address to?

In poking through the code, it looks like the PC App is saying, "If the address is F0, then it's eeprom..." so, I modified the HEX to show the EEPROM data at 0xF0 (and updated the checksum to match) and it still failed ... it looks like it wants to write EEPROM (if the "Erase eeprom" is checked) but the actual data is not written...

:0200000400F00A
:080000004527CABADDCABADDCA

Uploading EEPROM
send: 40, 00, 00, 01; FF, C0, 
receive: 43, 
send: 40, 00, 01, 01; FF, BF, 
receive: 43, 
send: 40, 00, 02, 01; FF, BE, 
receive: 43, 

You can see it's trying to upload eeprom, but sending only "FF" vs. the actual values in the HEX file.

[Anobium]

Using unchanged exe here. Does this have a bearing on this?

[Brendan]

I haven't changed the exe at all ... I've only changed the FW on the PIC. TMBL version is 0.14.6.5

[Brendan]

I haven't changed the exe at all ... I've only changed the FW on the PIC. TMBL version is 0.14.6.5

[Anobium]

I am confused.

The old rev 6 for another chip will not work. We have a PICAS rewrite of TBL.

Did we supply new TBL for tholis chip?

[Brendan]

The Q43 Bootloader I was using was 18F_Family15_TBL_REV6 which was provided by you for the Q43 chip ... however, I'm not using that FW at the moment, as it puts the corrupt data on the second half of the first page write (other thread)... However, the EEPROM writing issue I"m seeing is from the PC app.

Uploading EEPROM
send: 40, 00, 00, 01; FF, C0, 
receive: 43, 
send: 40, 00, 01, 01; FF, BF, 
receive: 43, 
send: 40, 00, 02, 01; FF, BE, 
receive: 43, 

As you can see, the PC app says it's sending EEPROM data ... but is only sending "FF" vs the actual EEPROM data in the hex file.

[Anobium]

See the picture.

Wrote the user HEX, the TBL EXE shows the bytes being sent by the EXE, and, then I read the EE using PK+ to see the results.

Looks ok?

[Anobium]

Please remember I did say that there was something odd about the User hex.

See attached what I am using.

[Brendan]

Looks great!

Yes, for some reason, XC8 v. 2.32 is putting FLASH, Then USER ID, Then CONFIG, then EEPROM (in ascending order) ... but when I flip that ... FLASH, EEPROM, CONFIG, USERID (as you did) it flashes correctly ...

Now to figure out why XC8 is doing that!

Thanks!