flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] Help

[Mikael N. <mik...@fl...>]

Probably the flash or eeprom is corrupted.

Maybe you did not erase the eeprom when you programmed the chip.

Reprogram the FF to the chip, with your programmer set  to erase flash 
and eeprom.

BR Mikael

On 2019-02-23 17:02, craig bair via Flashforth-devel wrote:
> Welcome in, Martin.
> If it gets that far, the system is usually good.  I'm used to seeing
> that on power-up, but a prompt comes back for me after hitting <ret>.
> I run the PIC18 and Arduino versions of FlashForth 5.0, what are you 
> using?
> craig bair
> 
> --------------------------------------------
> On Tue, 2/19/19, Martin Mainka <ma...@ma...> wrote:
> 
>  Subject: [Flashforth-devel] Help
>  To: fla...@li...
>  Date: Tuesday, February 19, 2019, 4:49 AM
> 
>  Hi, i am new to flashforth
> 
>  What to do if the system is only
>  responding ESC after the Flashforth
>  text, but no prompt? I did reset and
>  disconnect from power. No commands
>  are accepted.
> 
>  many thanks in advance
> 
>  Martin
> 
> 
> 
>  _______________________________________________
>  Flashforth-devel mailing list
>  Fla...@li...
>  https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] Help

[craig b. <dab...@ya...>]

Welcome in, Martin.
If it gets that far, the system is usually good.  I'm used to seeing that on power-up, but a prompt comes back for me after hitting <ret>.
I run the PIC18 and Arduino versions of FlashForth 5.0, what are you using?
craig bair

--------------------------------------------
On Tue, 2/19/19, Martin Mainka <ma...@ma...> wrote:

 Subject: [Flashforth-devel] Help
 To: fla...@li...
 Date: Tuesday, February 19, 2019, 4:49 AM
 
 Hi, i am new to flashforth
 
 What to do if the system is only
 responding ESC after the Flashforth
 text, but no prompt? I did reset and
 disconnect from power. No commands
 are accepted.
 
 many thanks in advance
 
 Martin
 
 
 
 _______________________________________________
 Flashforth-devel mailing list
 Fla...@li...
 https://lists.sourceforge.net/lists/listinfo/flashforth-devel
 

[Flashforth-devel] Help

[Martin M. <ma...@ma...>]

Hi, i am new to flashforth

What to do if the system is only responding ESC after the Flashforth
text, but no prompt? I did reset and disconnect from power. No commands
are accepted.

many thanks in advance

Martin

Re: [Flashforth-devel] status of Pic18FxxK42 FF-port?

[craig b. <dab...@ya...>]

Since I'm stuck in my work-life dealing with Cortex-M0+ chips from at least 4 chip makers, all the IDE-s are getting crossed in my head.  It's good to have an excuse to mix MPLabX into it just to play with relatively rational Microchip processors. (grin) 
...And you'll never get any arguement from me about anything that uses less memory AND fewer instruction cycles!  I wish the system designers thought that way. I've got a forth/pic-asm SPI-bit-bang kit I built that is probably going to need adapting, too.
I've got to get down to basics, run through the GIT starting tutorial and see if I can get Branch code, but I'll keep banging my head against it as much as I can get away with.

Keep smiling,
craig

--------------------------------------------
On Sat, 1/19/19, Mikael Nordman <mik...@fl...> wrote:

 Subject: Re: [Flashforth-devel] status of Pic18FxxK42 FF-port?
 To: "Jordan Niethe" <jni...@gm...>, dab...@ya...
 Date: Saturday, January 19, 2019, 1:52 AM
 
 Hi Jordan,
 I
 started to merge your K42 code to FF.
 
 I have no K42 chip so you and craig can maybe
 test it if you have time.
 
 I
 will be replacing most of the movffl instructions with movf,
 movwf 
 combinations. It uses less memory and
 clock cycles.
 
 BR Mikael
 
 On 2019-01-18 10:06, Jordan
 Niethe wrote:
 > Hi everyone,
 > Sorry I've been busy with other things
 these past months, so haven't
 > had
 time to work on the port lately.
 > There
 are a few problems that turned up while I was testing that
 I
 > have not been able to fix yet.
 > 
 > 1) There will
 occasionally be errors when sending files over UART
 > while the system tick (timer1) is
 enabled.
 > I had been getting around this
 by disabling the timer1 interrupt at
 >
 the beginning of a file, then enabling it again at the
 end.
 > $0001 $3994 mclr ( disable )
 > ....
 > $0001 $3994 mset
 ( enable )
 > I haven't been able to
 figure what exactly the problem is yet.
 >
 
 > 2) There were also problems with doing
 multiplication and division in
 >
 interrupts as in irqtest.txt which I have not figured
 out.
 > 
 > Apart from
 this I've have found it usable, but I could understand
 if
 > these are show stoppers.
 > Cheers,
 > Jordan.
 > 
 > On Thu, Jan 17, 2019
 at 10:54 PM craig bair via Flashforth-devel
 > <fla...@li...>
 wrote:
 >> 
 >>
 Thanks Mikael,
 >> I'll climb in
 there and see if my old brain can adapt to it (grin).
 >> 
 >> Keep up the
 good work.
 >> craig
 >> 
 >> 
 >>
 _______________________________________________
 >> Flashforth-devel mailing list
 >> Fla...@li...
 >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
 > 
 > 
 >
 _______________________________________________
 > Flashforth-devel mailing list
 > Fla...@li...
 > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
 
 -- 
 --
 Mikael
 

Re: [Flashforth-devel] status of Pic18FxxK42 FF-port?

[Jordan N. <jni...@gm...>]

Hi everyone,
Sorry I've been busy with other things these past months, so haven't
had time to work on the port lately.
There are a few problems that turned up while I was testing that I
have not been able to fix yet.

1) There will occasionally be errors when sending files over UART
while the system tick (timer1) is enabled.
I had been getting around this by disabling the timer1 interrupt at
the beginning of a file, then enabling it again at the end.
$0001 $3994 mclr ( disable )
....
$0001 $3994 mset ( enable )
I haven't been able to figure what exactly the problem is yet.

2) There were also problems with doing multiplication and division in
interrupts as in irqtest.txt which I have not figured out.

Apart from this I've have found it usable, but I could understand if
these are show stoppers.
Cheers,
Jordan.

On Thu, Jan 17, 2019 at 10:54 PM craig bair via Flashforth-devel
<fla...@li...> wrote:
>
> Thanks Mikael,
> I'll climb in there and see if my old brain can adapt to it (grin).
>
> Keep up the good work.
> craig
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] status of Pic18FxxK42 FF-port?

[craig b. <dab...@ya...>]

Thanks Mikael,
I'll climb in there and see if my old brain can adapt to it (grin).

Keep up the good work.
craig

Re: [Flashforth-devel] status of Pic18FxxK42 FF-port?

[Mikael N. <mik...@fl...>]

Sorry, I failed in keeping sourceforge and github in sync.

Now they are, so github also has the project files.

I recreated the because Microchip had done some format changes
and the migration of the old project files to the new format did not
work in mplabx.

There is fork a in github for the k42 put I don't know how well it 
works.

Check Jordans k42 branch here.
https://github.com/iamjpn/flashforth/tree/k42/pic18

BR Mikael

[Flashforth-devel] status of Pic18FxxK42 FF-port?

[craig b. <dab...@ya...>]

Hello fellow forth-fanatics!
	It's been a while since I've made a nuisance of myself here in the mailing list, but I grabbed one of the Xpress PIC18F46K42 boards from Microchip on year-end clearance and found myself wondering how far the port Jordan was working on got.  I'm supporting some lab-tool boards that run FlashForth on 18F46K22 chips and its looking like the K22-s are getting pushed back into "Relic" status in favor of the K40-s and K42-s.  I expect to have to migrate at some point, so I should probably get started...

	My experience with Git-Hub is limited to bringing the url up in my browser and doing a html download of the current flashforth-master.zip file then unpacking it to a subdirectory on my hard drive.  There, I frob with MPLab-X until things assemble and program up a chip to see if I did it right. (I seriously miss the old MPLab... It worked so well with MPAsm for its last decade.)

	Can I beg a few clues about what to look for in that Git-Hub Rat's Nest to locate anything relevant to the new PIC18-s? There doesn't appear to be a config for any of them in the master archive (ok, I'm half-blind but nothing greps up).

	I notice in a quick scan of the chip-specs that the 18FxxK40-s appear to be less of a change from our old standbys than the 18FxxK42-s are.  Perhaps they’d make a good interim migration step.  Either that or do a K42 first and have an easy step back to handle the K40...  Just random thoughts...

	I’m wandering badly so just let me say that any pointers or suggestions will be greatly appreciated and a big “Thank You!” in advance.

craig bair 
–- binary behaviorism for non-deterministic processors –-
                      --foreword into the past--

Re: [Flashforth-devel] FlashForth on the PIC18F26K42

[Jordan N. <jni...@gm...>]

Hi Mikael,
I've been working to get my changes integrated back in, and I've made
a tentative pull request to get some feedback.
I used your idea of the MOVFF macro, and ifdeffed the parts that where
different for the k42.
Do you think it has made it too unreadable?
In quite a few cases, it is just the register names + a banksel that
seperates the k42 from the others.
Perhaps having a set of defines so the k42 used the same name would be clearer?

It builds for the non-k42 chips, but I still need to test that it runs.
I've never made a pull request before, so I apologise in advance if I
have something there.
Looking foward to hearing your thoughts,
Thanks, Jordan.
On Wed, Sep 12, 2018 at 6:25 PM Mikael Nordman
<mik...@fl...> wrote:
>
> Hey Jordan.
>
> This is great !
> I suspected that it would be a substantial effort, so I did not even
> start.
>
> It would be best if you can merge master into the k42 branch and test
> that some  legacy PIC18 chips work with the code.
> After that the k42 branch can be merged to master and pulled to my main
> FF repository.
>
> I can contribute with testing on some legacy PIC18 chips, I have a
> fairly large selection.
>
> Part of merge can be done with ifdefs and part with macros.
> I wonder if movff can be macro or can movff be replaced by a M_MOVFF
> macro which generates
> movff or movffl instruction based on the selected chip. Using macros
> would make the code more readable than a myriad of ifdefs.
>
> Having a separate source file for the k42 could also be acceptable,
> since the k42 is so different.
> Or dividing FF into file(s) with common parts and file(s) with k42
> parts.
>
> BR Mikael
>
> On 2018-09-12 07:51, Jordan Niethe wrote:
> > Hi everyone,
> >
> > I have been working on getting FlashForth running on the PIC18F26K42
> > as part of my final year engineering project.
> > I thought people might be interested in my work to that end, which can
> > be seen at
> > https://github.com/iamjpn/flashforth on the k42 branch.
> >
> > The 26K42 has quite a few differences from the other PIC18s.
> > * The BSR is now 6 bits rather than 4 bits, and data memory ranges
> > from $0000-$3FFF.
> > However, for the 26K42, banks 16 - 55 are not implemented and banks 56
> > - 63 are SFR.
> > This made me decide to keep the same memory mapping as the other
> > PIC18s, with the RAM starting at $F000.
> > I further split the memory, to keep all the SFRs available:
> > $F000-$F7FF in FlashForth = $0000-$07FF in hardware
> > $F800-$FFFF in FlashForth = $3800-$3FFF in hardware
> >
> > All this requires a lot of bit masking, makes storing more complicated
> > and makes half the RAM unavailable.
> > It would be a better idea to just RAM at  $C000 on the 26K42, which is
> > what I'm now working on.
> >
> > The larger memory size also means that movff does not have enough
> > reach, movffl needs to be used.
> > You need to be using the latest MPASM or movffl will not work.
> > ( https://www.microchip.com/forums/FindPost/1064775 )
> >
> > * Many SFRs are no longer in the Access Bank.
> > A lot more bank selecting needs to be done.
> >
> > * No more USART.
> > The 26K42 has a new, different UART module, different code needed for
> > this.
> >
> > * Instruction Memory
> > The 26K42 uses a block size of 128 bytes for writing and erasing
> > program memory.
> > 64 bytes was previously assumed throughout FF.
> >
> > * Timers
> > Slightly different set up
> >
> > * EEPROM
> > Begins at address $310000 instead of $F00000
> >
> > * Naming
> > A few names used in FlashForth conflicted with names used by the
> > 26K42, so had to be renamed.
> >
> > I have not yet touched multitasking, HW flow control, cpu load, cpu
> > idle mode or USB serial emulation, will work on these next.
> > I have not used my changes in anger yet, but it seems to be
> > functional.
> >
> > The changes I have made make FlashForth no longer compatible with the
> > other PIC18s. After it is fully working on the 26K42 it would be nice
> > to integrate the changes back in.
> > I'm a little unsure what is the best way to go about this.
> > It would need quite a lot ifdefs if used in a similiar way to how
> > currently differences in devices are handled, but I'm not sure what a
> > better approach would be.
> >
> > I hope this is interesting to people,
> > Jordan Niethe.
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
> --
> --
> Mikael
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] FlashForth Operator Interrupts

[Mikael N. <mik...@fl...>]

Hi,
Added the labels for alternative interrupts into the PIC24 source code.

Now the alternative interrupt table should be correctly populated, even 
with the latest XC16 compiler.

BR Mikael

On 2018-10-03 15:33, Mikael Nordman wrote:
> Hi,
> It seems that later versions of the XC16 compiler has introduced a bug.
> When I use XC16 v1.35 the interrupt vectors are only filled into the
> IVT, not into the AIVT.
> Using XC16 1.21, then both tables are filled correctly.
> 

Re: [Flashforth-devel] FlashForth Operator Interrupts

[Mikael N. <mik...@fl...>]

Hi,
It seems that later versions of the XC16 compiler has introduced a bug.
When I use XC16 v1.35 the interrupt vectors are only filled into the 
IVT, not into the AIVT.
Using XC16 1.21, then both tables are filled correctly.

According to the documentation the XC16 compiler should initialize both 
interrupt vector tables automatically.
"Assembly language programmers can install interrupt handlers simply by 
following the standard naming conventions.
Interrupt handlers declared with the standard names and defined as 
globals are automatically installed into the vector tables."

Lyckily FlashForth has the int/ word that copies the IVT to the AIVT 
that can fix the situation.

BR Mikael


On 2018-10-02 08:50, Michael Garthe wrote:
> Thanks for the Info, Ill have a dig. The compiler I am currently
> using is XC16 1.35, I'll checkout 1.21 and step through both to see
> where differences arise. I'll keep you posted
> 
>  Thanks,
> 
>  Michael
> -------------------------
> 
> FROM: Mikael Nordman <mik...@fl...>
> SENT: 02 October 2018 15:44
> TO: Michael Garthe
> SUBJECT: Re: FlashForth Operator Interrupts
> 
> There could also be some compiler settings that affects this
> behaviour.
> Or the compiler versions can behave differently.
> I am using XC16 1.21.
> 
> BR Mikael
> 
> On 2018-10-02 07:24, Michael Garthe wrote:
>> Hello Mikael,
>> 
>> Thank you for your prompt reply, I had a look at the program memory
> in
>> the simulator and I tried both FF5.0 downloaded from sourceForge and
>> the latest code in the GitHub repo
>> https://github.com/oh2aun/flashforth. I tried all the PIC24 configs
>> and none of them had the Timer 1 or UartRx interrupt stored in aivt
> by
>> default, however when looking through the source code again I
> realised
>> the int/ restores vectors to the aivt (with PAIVT defined) and
> through
>> calling int/ with T1 and UxRX interrupt numbers they were loaded
>> successfully in the aivt. I know its not an ideal solution and I may
>> look into a more permanent solution when time permits, I'll let you
>> know if I figure it out.
>> 
>> Cheers again for the reply,
>> 
>> Michael
>> 
>>  [1]
>>  GitHub - oh2aun/flashforth: FlashForth development [1]
>>  FlashForth. FlashForth is a standalone Forth system for the
> Microchip
>> PIC 18, 24, 30, 33 and the Atmel Atmega series of microcontrollers.
> A
>> Forth system with interpreter, compiler, assembler and multitasker
> is
>> provided.
>>  github.com
>> 
>> -------------------------
>> 
>> FROM: Mikael Nordman <mik...@fl...>
>> SENT: 02 October 2018 01:03
>> TO: Michael Garthe
>> SUBJECT: Re: FlashForth Operator Interrupts
>> 
>> Hello Michael.
>> 
>> The interrupts used by FlashForth (T1, U1RX, U1TX, etc.)are stored
>> automatically both in the IVT and AIVT locations.
>> 
>> If you run FF in the MLABX IDE simulator, you can see in the program
>> memory view what is stored initially in the the tables.
>> 
>> If that does not work for you, maybe you have modified something ?
>> Maybe you have overwitten them in the AIVT by mistake ?
>> Or maybe a bug has creeped into FF.
>> 
>> BR Mikael
>> 
>> On 2018-10-01 09:47, Michael Garthe wrote:
>>> Hello Mikael,
>>> 
>>>  My name is Michael and I am using FlashForth for my final year
>>> engineering project, I tried signing up to the mailing list and
>>> posting my question there however I don't believe it ended up
> making
>>> it to the message board. I am doing some research into flash forth
>>> under supervision of Peter Jacobs, my research is based around the
>>> multi-tasking elements of the OS. One problem I have encountered
>>> during my use of flashforth with the PIC24FV32K family of chips is
>>> that the operator interrupts U1TX and U1RX are stored in the
> primary
>>> interrupt table whereas user interrupts are stored in the
>> alternative
>>> interrupt table, my problem arises when I try to mix the operator
>> and
>>> user interrupts, due to the interrupts being stored in different
>>> tables I can't use both at once. I was wondering if there's a
>>> parameter that needs setting before programming FlashForth on the
>>> chips to place the operator interrupts into the AIVT instead of the
>>> primary table, failing this I was wondering if there was an easy
> way
>>> to move an interrupt from one table to another or  if there's an
>> easy
>>> way to write the operator interrupts as user interrupts, I have
>> looked
>>> at the source code to try and do this however I have found it quite
>>> difficult, any advice or information you could give me on this
> would
>>> be greatly appreciated.
>>> 
>>>  Kind Reagrds,
>>> 
>>>  Michael Garthe :)
>> 
>> --
>> --
>> Mikael
>> 
>> 
>> Links:
>> ------
>> [1] https://github.com/oh2aun/flashforth
> 
> --
> --
> Mikael

-- 
--
Mikael

Re: [Flashforth-devel] Programming the ATMEGA2560

[Nils-Arne D. <nil...@gm...>]

A guide for programming one Arduino from another:
https://www.arduino.cc/en/Tutorial/ArduinoISP
Here is my guide specific for FlashFORTH:
http://unclebod.x10.mx/wp/?p=126

Should be possible to get that working with a bare chip also.

Den lör 22 sep. 2018 kl 16:16 skrev Mark Wills <mar...@gm...>:

> Hi
>
> Some time ago, I managed to burn FF into an ATMEGA328P without using an
> ISP programmer device. Thing is, I cannot remember how I did it, or where I
> got the information from!
>
> Was it/is it done using another Arduino as the ISP (running the ISP
> program available in the Arduino environment)?
>
> Any assistance in kick-starting my stressed brain would be very gratefully
> received.
>
> Thanks
>
> Mark
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

[Flashforth-devel] Programming the ATMEGA2560

[Mark W. <mar...@gm...>]

Hi

Some time ago, I managed to burn FF into an ATMEGA328P without using an ISP
programmer device. Thing is, I cannot remember how I did it, or where I got
the information from!

Was it/is it done using another Arduino as the ISP (running the ISP program
available in the Arduino environment)?

Any assistance in kick-starting my stressed brain would be very gratefully
received.

Thanks

Mark

Re: [Flashforth-devel] arduino

[hc <ml...@i2...>]

Ah I understand.

There are patches to Optiboot from 2015 that export the flash writing routine, 
and MCUDude has binaries.

https://github.com/MCUdude/optiboot_flash

"There is a jump table at the beginning of bootloader, so regardless of real address of 
do_spm function you can just jump to second instruction (+2B) after bootloader start. See 
here how it can be done in C: "

https://github.com/MCUdude/MiniCore/tree/master/avr/libraries/Optiboot_flasher

Of course, those don't seem to be what is coming from the factory in an 
arduino board, so they still need the initial flashing, somewhat defeating what I was 
hoping for.

It would however make it possible to make a single FF binary with arduino 
bootloader, so it could come from the factory with FF, be usable as arduino, 
and FF could be reloaded or upgraded at any time thereafter without a profgrammer. 
It would also mean that for a potential user, reflashing would not mean bricking it for 
arduino use.





On Saturday, 15 September 2018 18:12:32 NZST Mikael Nordman wrote:
> FlashForth needs to write to flash in order to compile new words.
> 
> Normally the bootloaders are set up so that only the bootloader can
> write to flash.
> And the bootloaders do not have an interface enabling the application
> code to write to flash.
> 
> Of course one could write special bootloader that offers what is needed.
> But then you anyway need to program the bootloader first into the chip.
> 
> On 2018-09-15 00:58, hc wrote:
> > What operation do you mean?
> > 
> > As I understand it, the bootloader
> > (https://github.com/Optiboot/optiboot)  is
> > generic (not arduino specific) and just loads the binary into the
> > absolute
> > addresses, except for the coldstart reset vector.
> > 
> > As long as FF is compiled below the bootloader area  ( top 512 bytes),
> > it
> > should load, and get run by the bootloader.
> > Perhaps some of the flags mapping the bootload area have to be
> > adjusted.
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

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
>>
>>
>

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
>
>

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

[Mikael N. <mik...@fl...>]

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
> 

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

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

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
>>
>

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

[Mikael N. <mik...@fl...>]

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
>> 

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

[Mikael N. <mik...@fl...>]

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
> 

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

[Mikael N. <mik...@fl...>]

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

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

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

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

[Flashforth-devel] Loop at Bootup : Pic18f45k20

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

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

Re: [Flashforth-devel] Trouble getting serial comms to work

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

Hi Craig,

thanks for your prompt response. I changed the baud to 9600 and can
confirm via Pulseview that the baud rate has indeed changed to 9600.

However, after the initial gibberish I now get a repeating pattern in
hex in the Pulseview UART decoder of D3 BE A0 FD 84 94 00.

After a bit of navel gazing becomes it dawns on me that the TTL logic
of the board is idle low, so I invert the sense in Pulseview and then
try decoding as least significant bit first and viola: the repeating
pattern could be:

 <space>SP?<space>ok

Which looks like a problem unrelated to serial comms now!

Looks like it's time to start another thread.

Thanks again for your help.

Kind regards
Richard


On 9/17/18, craig bair via Flashforth-devel
<fla...@li...> wrote:
> Hi yourself Richard,
>
> Running the calculation Microchip gives us:
>      ((12288000 / 38400) / 64) - 1 = 4
>   looks tight on the SPBRG, but the error is nill so the crystal should get
> it close enough.
>
> I occasionally have to reset my terminal program (TerraTerm) when it gets
> bloody-minded and acts like that.
>
> Old School Debugging would say try turning the starting comm-rate down to
> 9600 baud and see if it talks.
>
> It's been a while since I've had to do massive tweaking with my 18F46K22-s
> because Mikael's done a good job with the sources.
>
> Good Luck!
> craig bair
>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] Trouble getting serial comms to work

[Mikael N. <mik...@fl...>]

The config in git
config FOSC = INTIO67
uses the internal 8 MHz oscillator

The config should be changed to use the crystal instead.

BR Mikael