Thread: [Flashforth-devel] trying recent FF 5.0 on PIC24FV16KM202
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Peter J. <pe...@me...> - 2015-08-26 13:33:34
|
Mike,
After a long delay, I've returned to working with FF on a
PIC24FV16KM202, as I had used for the tutorial guide last year. I'm
building a couple of boards for one of my students. Since you have done
quite a bit of development on FF in recent times, I thought that I
should port my small number of edits for this processor onto your
current code for FF. Unfortunately, I have failed to get it working. I
can rebuild the FF code from April 2014 with the current MPLAB-X tools
and it runs nicely on the new boards, however, I get no boot message at
all with the current FF code.
I see in your new web pages that larger PIC24/dsPIC MCUs are mentioned
but not the 16KM202. Also, you suggest the MCU to have at least 24kB
flash. This may be my problem but MPLAB-X is indicating that 1099 words
are free following a build of the current FF code and that's not too
much less than the 1201 words free for the April 2014 FF code. It's
very likely that I forgotten to do something simple but I cannot see it
this evening.
If you have time to look and offer suggestions, I've put a complete copy
of both projects in the tar files:
(1) new code builds but doesn't run on the MCU
https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24-aug-2015-as-at-2015-aug-26.tar.gz
(2) old code builds and does run on the MCU
https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24fv32ka-apr-2014-as-at-2015-aug-26.tar.gz
The directory name makes this project seem like it's for another
processor but it really is for the 16KM202.
Within each project folder, I have a mercurial repository with a clean
copy your files as the initial commit.
Regards,
Peter J.
|
|
From: Mikael N. <mik...@fl...> - 2015-08-26 16:34:13
|
It turns out I made some changes in that broke the EEPROM read code in this commit :-( https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ I'll fix it soon. BR Mike On 26.08.2015 16:08, Peter Jacobs wrote: > Mike, > After a long delay, I've returned to working with FF on a > PIC24FV16KM202, as I had used for the tutorial guide last year. I'm > building a couple of boards for one of my students. Since you have > done > quite a bit of development on FF in recent times, I thought that I > should port my small number of edits for this processor onto your > current code for FF. Unfortunately, I have failed to get it working. > I > can rebuild the FF code from April 2014 with the current MPLAB-X > tools > and it runs nicely on the new boards, however, I get no boot message > at > all with the current FF code. > Regards, > Peter J. > |
|
From: Mikael N. <mik...@fl...> - 2015-08-27 19:04:11
|
Now it should work, please let me know. I don't have that chip. git pull BR Mike On 26.08.2015 19:34, Mikael Nordman wrote: > It turns out I made some changes in that broke the EEPROM read code > in > this commit :-( > > > https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ > > I'll fix it soon. > > BR Mike > > On 26.08.2015 16:08, Peter Jacobs wrote: >> Mike, >> After a long delay, I've returned to working with FF on a >> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm >> building a couple of boards for one of my students. Since you have >> done >> quite a bit of development on FF in recent times, I thought that I >> should port my small number of edits for this processor onto your >> current code for FF. Unfortunately, I have failed to get it >> working. >> I >> can rebuild the FF code from April 2014 with the current MPLAB-X >> tools >> and it runs nicely on the new boards, however, I get no boot message >> at >> all with the current FF code. >> > Regards, >> Peter J. >> |
|
From: Peter J. <pe...@me...> - 2015-08-27 23:37:19
|
Thank you. That's looking promising. I get the start-up message appearing but I need to do a little more fiddling to get the serial receive pin configured, I think. I've just used your current files and just changed the selected microcontroller in the project properties. I'll get back to this after class today. Cheers, Peter J. On 28/08/15 05:04, Mikael Nordman wrote: > Now it should work, please let me know. I don't have that chip. > > git pull > > BR Mike > > On 26.08.2015 19:34, Mikael Nordman wrote: >> It turns out I made some changes in that broke the EEPROM read code >> in >> this commit :-( >> >> >> https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ >> >> I'll fix it soon. >> >> BR Mike >> >> On 26.08.2015 16:08, Peter Jacobs wrote: >>> Mike, >>> After a long delay, I've returned to working with FF on a >>> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm >>> building a couple of boards for one of my students. Since you have >>> done >>> quite a bit of development on FF in recent times, I thought that I >>> should port my small number of edits for this processor onto your >>> current code for FF. Unfortunately, I have failed to get it >>> working. >>> I >>> can rebuild the FF code from April 2014 with the current MPLAB-X >>> tools >>> and it runs nicely on the new boards, however, I get no boot message >>> at >>> all with the current FF code. >>> >> Regards, >>> Peter J. >>> > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Peter J. <pe...@me...> - 2015-08-29 11:11:16
Attachments:
Screenshot-of-FF5-almost working-2015-08-29.png
|
Mike,
Your adjustment to the eeprom code allows the interpreter to start
and I can manipulate SRAM locations, however, if I try to make a
constant or define a new word, the interpreter aborts and restarts.
Screen shot attached.
Also, a secondary problem is that I don't seem to be able to get the
PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for running at 4
MIPS so this is not a show stopper. I have had the PLL running on this
chip from a C program but have not worked out how to coax FF into doing
the same.
Peter J.
On 28/08/15 09:37, Peter Jacobs wrote:
> Thank you. That's looking promising. I get the start-up message
> appearing but
> I need to do a little more fiddling to get the serial receive pin
> configured, I think.
> I've just used your current files and just changed the selected
> microcontroller
> in the project properties. I'll get back to this after class today.
> Cheers,
> Peter J.
>
> On 28/08/15 05:04, Mikael Nordman wrote:
>> Now it should work, please let me know. I don't have that chip.
>>
>> git pull
>>
>> BR Mike
>>
>> On 26.08.2015 19:34, Mikael Nordman wrote:
>>> It turns out I made some changes in that broke the EEPROM read code
>>> in
>>> this commit :-(
>>>
>>>
>>> https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/
>>>
>>> I'll fix it soon.
>>>
>>> BR Mike
>>>
>>> On 26.08.2015 16:08, Peter Jacobs wrote:
>>>> Mike,
>>>> After a long delay, I've returned to working with FF on a
>>>> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm
>>>> building a couple of boards for one of my students. Since you have
>>>> done
>>>> quite a bit of development on FF in recent times, I thought that I
>>>> should port my small number of edits for this processor onto your
>>>> current code for FF. Unfortunately, I have failed to get it
>>>> working.
>>>> I
>>>> can rebuild the FF code from April 2014 with the current MPLAB-X
>>>> tools
>>>> and it runs nicely on the new boards, however, I get no boot message
>>>> at
>>>> all with the current FF code.
>>>>
>>> Regards,
>>>> Peter J.
>>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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
|
|
From: Peter J. <pe...@me...> - 2015-08-29 11:29:03
|
A more compact message with some example interaction included as text. BPE FlashForth PIC24 27.08.2015 ok<#,ram> ok<#,ram> $0744 constant clkdiv AS FlashForth PIC24 27.08.2015 $0744 @ hex u. 0 ok<$,ram> $0742 @ u. 7710 ok<$,ram> : sqr dup * ; AS FlashForth PIC24 27.08.2015 On 29/08/15 21:10, Peter Jacobs wrote: > Mike, > Your adjustment to the eeprom code allows the interpreter to start > and I can manipulate SRAM locations, however, if I try to make a > constant or define a new word, the interpreter aborts and restarts. > Screen shot attached. > Also, a secondary problem is that I don't seem to be able to get > the PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for > running at 4 MIPS so this is not a show stopper. I have had the PLL > running on this chip from a C program but have not worked out how to > coax FF into doing the same. > Peter J. > > On 28/08/15 09:37, Peter Jacobs wrote: >> Thank you. That's looking promising. I get the start-up message >> appearing but >> I need to do a little more fiddling to get the serial receive pin >> configured, I think. >> I've just used your current files and just changed the selected >> microcontroller >> in the project properties. I'll get back to this after class today. >> Cheers, >> Peter J. >> >> On 28/08/15 05:04, Mikael Nordman wrote: >>> Now it should work, please let me know. I don't have that chip. >>> >>> git pull >>> >>> BR Mike >>> >>> On 26.08.2015 19:34, Mikael Nordman wrote: >>>> It turns out I made some changes in that broke the EEPROM read code >>>> in >>>> this commit :-( >>>> >>>> >>>> https://sourceforge.net/p/flashforth/code/ci/f5563da4acad608e5fff53d9ed223853b780302e/ >>>> >>>> >>>> I'll fix it soon. >>>> >>>> BR Mike >>>> >>>> On 26.08.2015 16:08, Peter Jacobs wrote: >>>>> Mike, >>>>> After a long delay, I've returned to working with FF on a >>>>> PIC24FV16KM202, as I had used for the tutorial guide last year. I'm >>>>> building a couple of boards for one of my students. Since you have >>>>> done >>>>> quite a bit of development on FF in recent times, I thought that I >>>>> should port my small number of edits for this processor onto your >>>>> current code for FF. Unfortunately, I have failed to get it >>>>> working. >>>>> I >>>>> can rebuild the FF code from April 2014 with the current MPLAB-X >>>>> tools >>>>> and it runs nicely on the new boards, however, I get no boot message >>>>> at >>>>> all with the current FF code. >>>>> >>>> Regards, >>>>> Peter J. >>>>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 > |
|
From: Mikael N. <mik...@fl...> - 2015-08-30 17:37:37
|
Could you send me your config. M On 29.08.2015 14:10, Peter Jacobs wrote: > Mike, > Your adjustment to the eeprom code allows the interpreter to start > and I can manipulate SRAM locations, however, if I try to make a > constant or define a new word, the interpreter aborts and restarts. > Screen shot attached. > Also, a secondary problem is that I don't seem to be able to get > the PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for > running at 4 MIPS so this is not a show stopper. I have had the PLL > running on this chip from a C program but have not worked out how to > coax FF into doing the same. > Peter J. > |
|
From: Mikael N. <mik...@fl...> - 2015-09-01 18:39:48
|
Todays FF finally works with the PIC24FV32KA302. The PMD4 disabled the eeprom which was not good :-) It was not easy to find that bug, so for now all peripherals are left powered at startup. For PIC24FV16KM202 the ff30.inc include file and a new device cinfig file is needed. BR Mike On 30.08.2015 20:37, Mikael Nordman wrote: > Could you send me your config. > M > > On 29.08.2015 14:10, Peter Jacobs wrote: >> Mike, >> Your adjustment to the eeprom code allows the interpreter to >> start >> and I can manipulate SRAM locations, however, if I try to make a >> constant or define a new word, the interpreter aborts and restarts. >> Screen shot attached. >> Also, a secondary problem is that I don't seem to be able to get >> the PLL to run. Using config FOSCSEL, FNOSC_FRCDIV is fine for >> running at 4 MIPS so this is not a show stopper. I have had the PLL >> running on this chip from a C program but have not worked out how to >> coax FF into doing the same. >> Peter J. >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-09-01 18:42:45
|
Now FF should compile and work also with the PIC24F(V)KA KM and KL chips. ! BR Mikael On 01.09.2015 20:47, Mikael Nordman wrote: > Todays FF finally works with the PIC24FV32KA302. > The PMD4 disabled the eeprom which was not good :-) > It was not easy to find that bug, so for now all peripherals are left > powered at startup. > > For PIC24FV16KM202 the ff30.inc include file and a new device cinfig > file is needed. > > BR Mike |
|
From: Peter J. <pe...@me...> - 2015-09-02 11:44:04
|
Almost, yes. The two new config files are missing from your commit, I think. Error: Project "FF" refers to file "p24fka_config.inc" which does not exist in the disk. The project failed to load. Error: Project "FF" refers to file "p24fkm_config.inc" which does not exist in the disk. The project failed to load. Regards, Peter J. On 02/09/15 04:42, Mikael Nordman wrote: > Now FF should compile and work also with the PIC24F(V)KA KM and KL > chips. ! > > BR Mikael > > On 01.09.2015 20:47, Mikael Nordman wrote: >> Todays FF finally works with the PIC24FV32KA302. >> The PMD4 disabled the eeprom which was not good :-) >> It was not easy to find that bug, so for now all peripherals are left >> powered at startup. >> >> For PIC24FV16KM202 the ff30.inc include file and a new device cinfig >> file is needed. >> >> BR Mike > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-09-02 12:13:57
|
Actually the files are not missing, and should not be needed. It is only the MPLABX project that is referring to those obsolete files. I was very happy to find a setup the only needs one config file for all the K chips. There was evidence of some incompatible NVMCON settings for some chips. It turned out to be a fault in the old version of the datasheet. I need to commit correct project files. BR Mikael On 02.09.2015 14:43, Peter Jacobs wrote: > Almost, yes. The two new config files are missing from your commit, > I > think. > > Error: Project "FF" refers to file "p24fka_config.inc" which does not > exist in the disk. The project failed to load. > Error: Project "FF" refers to file "p24fkm_config.inc" which does not > exist in the disk. The project failed to load. > > Regards, > Peter J. > > |
|
From: Peter J. <pe...@me...> - 2015-09-02 22:57:17
|
Very nice. You've made my day. I've now had it running on PIC24FV32KA302 and PIC24FV16KM202, with the bonus that the PLL is running. ok<#,ram> ok<#,ram> warm S FlashForth PIC24 01.09.2015 $0742 constant osccon ok<#,ram> bin ok<%,ram> osccon @ u. 1000100110000 ok<%,ram> decimal ok<#,ram> Fcy u. 16000 ok<#,ram> I see your comment in the pic24fk_config.inc file that the normal config macros did not work. That may have been my problem with the PLL for a long time now. For the first time on these chips, I can see the PLL lock bit set while FF is running. Cheers, Peter J. On 02/09/15 22:13, Mikael Nordman wrote: > Actually the files are not missing, and should not be needed. > > It is only the MPLABX project that is referring to those obsolete > files. > > I was very happy to find a setup the only needs one config file for all > the K chips. > > There was evidence of some incompatible NVMCON settings for some chips. > It turned out to be a fault in the old version of the datasheet. > > I need to commit correct project files. > > BR Mikael > > On 02.09.2015 14:43, Peter Jacobs wrote: >> Almost, yes. The two new config files are missing from your commit, >> I >> think. >> >> Error: Project "FF" refers to file "p24fka_config.inc" which does not >> exist in the disk. The project failed to load. >> Error: Project "FF" refers to file "p24fkm_config.inc" which does not >> exist in the disk. The project failed to load. >> >> Regards, >> Peter J. >> >> > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Peter J. <pe...@me...> - 2015-09-03 12:32:55
|
Mike, I am extra pleased this evening... By adding SOSCSRC_DIG to the __FOSCSEL setting, I now get control of RA4 and RB4 as digital outputs. Of course this is completely unsurprising but it is something that I haven't been able do for the past year from within FF. I had been able to do so from within a C program on the very same chips. There has to be something dodgy with the XC16-supplied macro (or the assembler handling of it) for setting the config words on the K-series chips. Cheers, Peter J. On 03/09/15 08:57, Peter Jacobs wrote: > Very nice. You've made my day. > I've now had it running on PIC24FV32KA302 and PIC24FV16KM202, with the > bonus that the PLL is running. > > ok<#,ram> > ok<#,ram> > warm S FlashForth PIC24 01.09.2015 > > $0742 constant osccon ok<#,ram> > bin ok<%,ram> > osccon @ u. 1000100110000 ok<%,ram> > decimal ok<#,ram> > Fcy u. 16000 ok<#,ram> > > I see your comment in the pic24fk_config.inc file that the normal config > macros did not work. > That may have been my problem with the PLL for a long time now. > For the first time on these chips, I can see the PLL lock bit set while > FF is running. > > Cheers, > Peter J. > > > On 02/09/15 22:13, Mikael Nordman wrote: >> Actually the files are not missing, and should not be needed. >> >> It is only the MPLABX project that is referring to those obsolete >> files. >> >> I was very happy to find a setup the only needs one config file for all >> the K chips. >> >> There was evidence of some incompatible NVMCON settings for some chips. >> It turned out to be a fault in the old version of the datasheet. >> >> I need to commit correct project files. >> >> BR Mikael >> >> On 02.09.2015 14:43, Peter Jacobs wrote: >>> Almost, yes. The two new config files are missing from your commit, >>> I >>> think. >>> >>> Error: Project "FF" refers to file "p24fka_config.inc" which does not >>> exist in the disk. The project failed to load. >>> Error: Project "FF" refers to file "p24fkm_config.inc" which does not >>> exist in the disk. The project failed to load. >>> >>> Regards, >>> Peter J. >>> >>> >> ------------------------------------------------------------------------------ >> Monitor Your Dynamic Infrastructure at Any Scale With Datadog! >> Get real-time metrics from all of your servers, apps and tools >> in one place. >> SourceForge users - Click here to start your Free Trial of Datadog now! >> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-09-03 19:44:39
|
I checked in some further improvements for the FK series. The Interrupt vectors are moved from ram to flash, freeing up 256 bytes of the 1 to 2 K of ram on these chips. And there is a new word INT/ ( vector-no -- ) that restores the original vector in the alternate table if you happen write some crap into the table. Hope I did not break anything. BR Mike On 03.09.2015 15:32, Peter Jacobs wrote: > Mike, > I am extra pleased this evening... > > By adding SOSCSRC_DIG to the __FOSCSEL setting, I now get control of > RA4 > and RB4 as digital outputs. Of course this is completely > unsurprising > but it is something that I haven't been able do for the past year > from > within FF. I had been able to do so from within a C program on the > very > same chips. > > There has to be something dodgy with the XC16-supplied macro (or the > assembler handling of it) for setting the config words on the > K-series > chips. > |
|
From: Peter J. <pe...@me...> - 2015-09-04 01:19:37
|
It seems to be working fine on the PIC24FV16KM202 that I have on the desk here. Thank you. Peter J. On 04/09/15 05:44, Mikael Nordman wrote: > I checked in some further improvements for the FK series. > > The Interrupt vectors are moved from ram to flash, freeing up 256 bytes > of the 1 to 2 K of ram on these chips. > > And there is a new word INT/ ( vector-no -- ) that restores the > original vector > in the alternate table if you happen write some crap into the table. > > Hope I did not break anything. > BR Mike > > On 03.09.2015 15:32, Peter Jacobs wrote: >> Mike, >> I am extra pleased this evening... >> >> By adding SOSCSRC_DIG to the __FOSCSEL setting, I now get control of >> RA4 >> and RB4 as digital outputs. Of course this is completely >> unsurprising >> but it is something that I haven't been able do for the past year >> from >> within FF. I had been able to do so from within a C program on the >> very >> same chips. >> >> There has to be something dodgy with the XC16-supplied macro (or the >> assembler handling of it) for setting the config words on the >> K-series >> chips. >> > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X