26K22 - the continuing saga [solved]

[strud]

For some time I've been working away at getting this bootloader to work on a 26K22.

Many of the posts here helped me a great deal, however I now have a rather curious problem after resolving most of my issues.

I now have it running such that the bootloader GUI communicates with the micro, but the response is disappointing.

sent -> 0xC1
sent back-> 0x57 0x83 0x02 0x4B

So it fails on the echo test, and is identifying with a device number of 131 instead of 343

The DEVICEID is confirmed as 343 in the compilation using the messg mechanism

I have added the following to my code to confirm Tx can work :

; send test message out uart1
movlw 0x2A ; load * ascii code
movwf TXREG1
rcall Send

Strangely two asterix chars are sent, hence maybe this is part of my problem, however it is at least sending the correct character.

Have tried the same code at 16MHz & 64Mhz (with and without x4 PLL) and also with high and low baud rates eg 19200 and 115200.

Suggestions where to look ?

Craig

---

I have added the following to my code to confirm Tx can work :

; send test message out uart1
movlw 0x2A ; load * ascii code
movwf TXREG1
rcall Send

Strangely two asterix chars are sent, hence maybe this is part of my problem, however it is at least sending the correct character.

Fixed that problem, rather stupidly had not initially realised the "movwf TXREG1" was not required....

So, point is that this mechanism sends the correct data ie an asterix appears when observed in Teraterm.

CS

[strud]

Oh and using the SendL macro works too

ie : SendL (0x2A)

Successfully sends an asterix as received in teraterm and captured in my logic analyser.

The attachments show the strange behaviour of the incorrect data coming back.

   

   

[Mikael Gustavsson]

Hi,
Why is echo verification enabled in the GUI?

[strud]

An error on my part it seems.

For some reason I thought this was a default setting that was required and hence when I couldn't see how the firmware implemented it I assumed I may have missed something.

[strud]

So after deselecting the echo option, it all seems to work. (Note this echo option seems to be the default setting for me so I have to keep de-selecting it.)

However, it is a bit finicky ie not all of my hex files are working with the bootloader. Iam using MikroC Pro for PIC v5.80 as a compiler, and this particular hex file generates an error when selected in the ds30loader

"Validating hexfile...line 897 is empty
Hex file validation failed
Hex file parse failed"

A previous revision of this project hex file works fine and downloads without issue. However, the latest compilation crashes the GUI reliably.

The bootloader is discovered and the ok is returned. As soon as the GUI starts to download the firmware, it crashes and only with this version of the firmware.

I suspect it is occurring due to the parsing problem but I don't know what I can do about it.

problematic hex file attached along with screen dump of error.

CS

---

Hmmm

Just added a nop opearation to the program, recompiled and it works fine through the bootloader......

All good now I guess.

CS

---

So, the last bit of my last post was a little too soon.

Unfortunately when I selected the problematic hex file it didn't load it and hence the previously selected one was parsed and downloaded just fine, giving the illusion that all was well.

So the problem still stands and the addition of a nop here and there doesn't resolve the issue.

If anyone is able to suggest a work around that would be great. I'm not aware of what to be looking at in the hexfile, however the confusing thing is that the hexfile does not have as many lines as the GUI is saying the error occurs at ie line 897 ?

CS

[Mikael Gustavsson]

Thank you for the bug report. You can just delete one of the two empty lines at the end of the file. I will fix this to the next release.

[strud]

Thanks, that solved the problem !

CS