PIC16F1614 troubles

[BRIAN CLICK]

Hi, I modified the original from Dan's FWUpdate_8 zip archive (Dan_tinybld16F1614-1615-1618-1619_int16MHz_19200_r1.asm)

I used Device Type 0x27 (not 0x28) because the PIC16F16xx are HEF, not EEPROM

At first, Check Device would fail. I then found the TXREG value was incorrect (line 203)

retlw   B'00010010'     ;select TX

for this processor, it needs to be

retlw   B'00000110'     ;select TX

After that change, some progress. Check Device is OK...

Checking device
Open COM12 serial port at 19200 Baud Rate
Hardware RTS resetting device
Device answer: 0x27 0x42='B'
byte OK, now check ID-code and Family
idCode = $27
family = B
description = 16F w/4Kw flash & 0B EEPROM (Blk32)
flash mem = 8192 bytes
EEPROM mem = 0 bytes
Bootloader size = 200 bytes
Transfer block size = 64 bytes
Device detected: '16F w/4Kw flash & 0B EEPROM (Blk32)'
Closed COM12 serial port
TinyBootLoader+ device check completed

My problem is when trying to Write Device:

Source HEX file opened: C:\Code\MyLCDTest.HEX
Hex file verified, OK
Warning: Config found just writing data
minMemPos=00000000, maxMemPos=00001F40, blockSize=64
first 4 words at address 0x0F9C:
0x018A
0x01B2
0x2884
0x0000
Uploading flash
Uploading program memory
write mem pos: 0x00000000(byte)
send: EEADRH=0x00, EEADRL=0x00(word), block=64
0F 30 8A 00 A0 2F FF FF B2 16 B2 1E B2 12 32 19 0E 28 FE 39 B3 00 32 15 03 10 81 28 32 1A 16 28 A6 00 32 16 31 20 03 18 1B 28 26 08 39 20 03 18 1B 28 B2 1E 81 28 28 20 54 20 32 11 32 12 B2 11
no answer
ERROR: Problem in uploading HEX file to device
Closed COM12 serial port
TinyBootLoader+ completed

No answer?!?

The Debug window shows this:

Uploading program memory
send: 00, 00, 40; 0F, 30, 8A, 00, A0, 2F, FF, FF, B2, 16, B2, 1E, B2, 12, 32, 19, 0E, 28, FE, 39, B3, 00, 32, 15, 03, 10, 81, 28, 32, 1A, 16, 28, A6, 00, 32, 16, 31, 20, 03, 18, 1B, 28, 26, 08, 39, 20, 03, 18, 1B, 28, B2, 1E, 81, 28, 28, 20, 54, 20, 32, 11, 32, 12, B2, 11, D5,
TinyBootLoader+ completed

Any ideas?

[Anobium]

Set the PPS?
If TX was wrong then RX wil be.

We can produce a TBL+ for you. It costs £15. Send me PM for details.

This is the report from the generator.

TOOLVERSION .......... 1.06B



IDTYPEPIC............  $A5 [PICCODES.INI] 
CHIP ................. 16F1614 / 14 PINS
FREQUENCY ............ 32 Mhz
OSCILLATOR SOURCE .... INTERNAL
BAUD RATE ............ 19200 BPS
PROGMEM WORDS ........ 4096
RAM BYTES ............ 512
CHIPFAMILY ........... 15
PPSCHIP .............. YES
PPSCONFIGDEFINED ..... YES
PPSTOOLPART .......... 16F1614
CHIPARCHITECTURE ..... 2


TIMERDELAY ........... 2 SECS


CONFIG:
      CONFIG1, CLKOUTEN_OFF & CP_OFF & _MCLRE_ON & _FOSC_INTOSC
      CONFIG2, _LVP_OFF & _PLLEN_OFF & _WRT_OFF
      CONFIG3, _WDTE_OFF

RC5PPS = 0X0006 : ANSELC.4 = 0   'TX > RC5 & RX > RC4 FOR 14 PINS DEVICE.

MEMORY USAGE MAP ('X' = Used,  '-' = Unused)
     0000 : XX-------------- ---------------- ---------------- ----------------
     0F80 : ---------------- ------------XXXX XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX
     0FC0 : XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX XXXXXXXX--------
     8000 : -------XXX------ ---------------- ---------------- ----------------
     All other memory blocks unused.
     Program Memory Words Used:    97
     Program Memory Words Free:  3999


Recommendations for your solution:

      As shown above, in this report, specific CONFIG bits are set to specific values.
      All other CONFIG bits are set to the default value

      As shown above, in this report, PPS may have been used to set up the USART.
      You MUST consider the impact of the bootloader use of PPS in your solution.
      As the bootloader exits, handing of the processing to your program, the USART is disabled, however,
      You MUST set/disable PPS on the specified ports (PPS registers will have the substring of `PPS`), or, set the PPS registers used to a state that you required.


      As shown above, in this report, a memory map is provided
      You MUST ensure your program does not overwrite these memory location using SelfWrite or the program size.
      You MUST also consider the page size of the specific chip selected with also constrain the maximum program size.



05/10/2023 06:45:13 

[BRIAN CLICK]

Evan

Thanks for your reply. It's not a boot time issue, so the memory map concerns aren't a factor in the matter at hand. I've used TinyBL (the Claudiu build) on other projects since 2009 so I do understand how to set it all up and use it properly. The CONFIG block in the BL is lifted from my application code; this is not a concern.

Yes I set PPS as required, same as in my application code, in which I employ the USART and that works fine. And Rx DOES work in the BL, as evidenced by the response to 0xC1 in the init.

One quandary - your BTL generator report shows $A5 as the device type, my piccodes.ini shows THIS however:

$A5, E, PIC24FJ w/128KB flash, $2B000, 0, default, default,

Is "your" piccodes.ini different than the SourceForge release? I'm using V11 because the later version installer is unsigned and my security policy disallows installing it. A zipfile distro would be nice.

I suspect the byte/block count isn't correct or the BL counter isn't working properly - it looks to me that the BL is waiting for more data but the app is expecting a response. I'll figure it out

Cheers

[BRIAN CLICK]

Sorted. The app sends a 2's complement checksum and the BL is using a simple rolling byte adder. The Release Notes for v14 (which I am NOT using) mentions something about a "crc" fix...

v0.14.x (jan 2021)
-------------------
PC Software:
Added new config option to improve performance. Select Force block transfer to send data in blocks, not, byte by byte.
Added EEPROM 18f write operations now support 18fxxq10,18fxxq41, 18fxxq43
Fix to CRC calculations <--THIS

BTW it is a CHECKSUM being employed here, not a Cyclical Redundancy Check. No way an ASM CRC routine will fit in <100 bytes.

:-(

No beer money

[Anobium]

Well done.

The new code we developed does not call it CRCm you are spot on - it is a checksum.

I have just completed a new development so TBL+ now supports all the new chips from Microchip including 18FxxQxx, 18FxxK83 and 18FxxK84 etc using PIC-AS.

The video shows the result of a lot of development effort.

.