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

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

As I said at the outset, something silly.

Turns out that the circuit diagram was wrong and it was not TTL logic
on the port I was using. Instead it was in fact true RS232. Which is
of course inverted to TTL logic.

The voltage levels were a bit low which is why I didn't pick it up.

Sorry to have wasted everyone's time.

regards
Richard

On 9/18/18, Richard Burden <ric...@gm...> wrote:
> 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
>>
>>
>