Re: [Flashforth-devel] Loop at Bootup : Pic18f45k20

[Richard B. <ric...@gm...>]

Hi Mikael

Thank you for your assistance. I do understand the time this consumes and
appreciate your help.

I read the device and the first 6 or so bytes of eeprom were not $ff. So I
erased the chip and reprogrammed it. The looping has now gone.

It seems I am close.  My initial test with the logic analyser showed the
welcome message. ie
BP FlashForth 5 PIC18FK20 20.03.2018crlf
 ok<#,ram>crlf
$11

That last line was without the $

Unfortunately on the serial terminal it is garbled because of the inversion
problem. If I invert the Rx in the logic analyser the printable characters
match the terminal display.

I can see that the Rx line is idle high and the TX line is idle low. And
what appears on the Rx line is shortly afterwards echoed on the TX line,
but inverted. This TX idle low supports a view that the user operation has
been inverted by writing 1 to the cktxp bit in the baudcon register. I'll
trawl through the assembly listing to see if I can see this happening.

Kind regards
Richard


On Tue., 18 Sep. 2018, 8:36 pm Mikael Nordman, <
mik...@fl...> wrote:

> Hi Richard.
>
> Based on your analysis of your TX data I am pretty convinced that the
> PROMPT vector in EEPROM is corrupt.
>
> The cold initialization of the vectors is triggered by 0xff in the first
> two EEPROM bytes.
> If the contents is not 0xff then whatever data happens to be in the
> PROMPT vector is used as an
> execution address. A random address there FF go haywire.
>
> So make sure that your device programmer(pickit etc.) erases the eeprom
> before programming FF into the chip.
> Erasing the device will set the eeprom contents to 0xff.
>
> If you download the FF that I updated yesterday, it does not execute the
> PROMPT vector directly at startup.
> So there should not be any garbage in the TX.
>
> That allows you to give the EMPTY command in case the EEPROM has some
> corrupt values.
> EMPTY will write the correct initialization values into EEPROM.
>
> If it still does not work you may have defect chip.
>
> BR Mikael
>
>
>
> On 2018-09-18 13:14, Richard Burden wrote:
> > Well, there is no signal on Pin 1 (RX) whatsoever. So it seems the Tx
> > data is the result of some kind of program error. I'll have to think
> > about this some more. But at present it has me stumped.
> >
> > Regards
> > Richard
>
>