Thread: [Flashforth-devel] Loop at Bootup : Pic18f45k20
Brought to you by:
oh2aun
From: Richard B. <ric...@gm...> - 2018-09-17 14:04:04
|
Hi all, now that I have serial comms working I'm stuck with the following at boot: y½Ö}ýs'=/s!¿¿_mysi¿££åë¿!)¿Y_¿!)L ¿*¿}w¿!)l¿*¿}w¿!)t¿*¿}w¿!) ¿*¿}w¿!)t¿*¿}w¿!) ¿*¿}w¿!)t¿*¿}w¿!) ¿*¿}w¿!)\¿*¿}w¿!)d¿*¿}w¿!)¿*¿}w¿!)g³vÖöSöV6ööëÝ¿!)t¿*¿}w¿!)¿*¿}w¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!)Ë}¿!) If I decode with Pulseview I can see that the repeating characters, when changed to least significant bit first, are a repeating string of : "<space>SP?<space>ok" There is a delay of almost 10ms after "ok" until the sequence starts with the space character again. I'm not sure why the Pic is sending data like this, and why the loop is occurring. But the two issues could be related. Any guidance would be gratefully appreciated. Kind regards Richard |
From: Richard B. <ric...@gm...> - 2018-09-17 14:18:07
|
The full "gibberish" is as follows: [[BP FlashForth 5 PIC18F45K20 20.03.2018[[ ok SP? ok61937 50418 AD? ok27633 50420 AD? ok14336 50422 AD? ok769 50424 AD? ok14336 50426 AD? ok769 50428 AD? ok143 <snip since this goes on and on> then the repeating pattern of <space>SP?<space>ok If anyone has a clue it would be appreciated. Kind regards Richard |
From: Mikael N. <mik...@fl...> - 2018-09-17 14:35:24
|
Richard, You mentioned that your serial connection has the wrong electrical polarity. Maybe you should fix that first. It could be the PIC UART is continuously receiving something, because it is not idle. And that makes the interpreter send out these error messages. BR Mikael |
From: Mikael N. <mik...@fl...> - 2018-09-17 15:29:27
|
Another possibility is that your eeprom initialization fails. After the first ok has been printed, FlashForth tries to execute the .st word. That seems to fail because there is some garbage in the eeprom. You need to set your device programmer to erase the eeprom to 0xff. I have my pickit set to erase all memories before programming. Otherwise FlashForth initialization will fail to initialize the .st vector correctly. BR Mikael On 2018-09-17 17:17, Richard Burden wrote: > The full "gibberish" is as follows: > > [[BP FlashForth 5 PIC18F45K20 20.03.2018[[ ok SP? ok61937 50418 AD? > ok27633 50420 AD? ok14336 50422 AD? ok769 50424 AD? ok14336 50426 AD? > ok769 50428 AD? ok143 > |
From: Mikael N. <mik...@fl...> - 2018-09-17 18:37:01
|
Richard, If you download FlashForth dated 17.9.2018, the PIC18 code is changed so that the PROMPT vector that executes .ST is now executed after the first line after reset/abort has been interpreted. So even if your eeprom is corrupted, you can give the command EMPTY as first command after reset. It will initialize the eeprom correctly. I had moved the PROMPT the beginning of QUIT to get it before the first line is input, but that took some of the robustness away. But now it's fixed. The PIC24 and Atmega still has the original behaviour. BR Mikael On 2018-09-17 18:29, Mikael Nordman wrote: > Another possibility is that your eeprom initialization fails. > After the first ok has been printed, FlashForth tries to execute the > .st word. > That seems to fail because there is some garbage in the eeprom. > > You need to set your device programmer to erase the eeprom to 0xff. > I have my pickit set to erase all memories before programming. > > Otherwise FlashForth initialization will fail to initialize the .st > vector correctly. > > BR Mikael > > On 2018-09-17 17:17, Richard Burden wrote: >> The full "gibberish" is as follows: >> >> [[BP FlashForth 5 PIC18F45K20 20.03.2018[[ ok SP? ok61937 50418 AD? >> ok27633 50420 AD? ok14336 50422 AD? ok769 50424 AD? ok14336 50426 AD? >> ok769 50428 AD? ok143 >> |
From: Richard B. <ric...@gm...> - 2018-09-18 10:14:25
|
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 On 9/18/18, Richard Burden <ric...@gm...> wrote: > Mikael > > Thanks for the advice. The polarity was simply an artefact of how the > decoder worked out of the box. > > I am suspicious that the device has pins 1 (Rx) and 8(rb0 int0) connected. > Tonight I'll put a cro there to see if there is anything amiss. > > Kind regards > Richard > > On Mon., 17 Sep. 2018, 10:35 pm Mikael Nordman, < > mik...@fl...> wrote: > >> Richard, >> You mentioned that your serial connection has the wrong electrical >> polarity. >> >> Maybe you should fix that first. >> >> It could be the PIC UART is continuously receiving something, because it >> is not idle. And that makes the interpreter send out these error >> messages. >> >> BR Mikael >> >> >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > |
From: Mikael N. <mik...@fl...> - 2018-09-18 12:36:42
|
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 > |
From: Richard B. <ric...@gm...> - 2018-09-18 14:08:27
|
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 > > |
From: Richard B. <ric...@gm...> - 2018-09-19 08:27:08
|
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 >> >> > |