Thread: [Flashforth-devel] FF5.0 on PIC24FV32KA302 -- a couple of issues
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Peter J. <pe...@me...> - 2014-04-17 12:11:12
|
Gentlemen,
I've had some success getting FF5.0 to run on a PIC24FV32KA302 but
have a couple of issues.
(a) I can't seem to get the FRCPLL config option to behave as if the PLL
is actually on. I measure a very nice 4.00MHz CLK0 signal on the OSCO
pin whether I choose FRCDIV or FRCPLL. This is probably my simple bug
in the way I've set the config registers. Relevant bits from the config
file below.
(b) The more troublesome issue is the UART silicon bug in my revision 4
chips. There is a work-around of not completely filling the buffer but
I think that requires fiddling with the interrupt or queue code, which
is a bit beyond my capability at the moment. I added a little bit of
code to the main program, as shown below.
Suggestions for an easy fix (hopefully)?
The motivation for playing with this particular processor is that it
looked to be a nice 16-bit complement to the PIC18F26K22 and the
ATmega328P processors which I'm using for the rework the FF tutorial
documents. The FV32KA also runs nicely at 5V. If there's no simple
fix, I'll choose another processor.
Regards,
Peter J.
-----------------------------------------------------------
p24f16ka_config.incafter line 4
-----------------------------------------------------------
.ifdef __24F16KA102
;;; Below is the setting for max amount of ram for PIC24F16KA102
.equ FLASH_SIZE, 0x2C00 ; Flash size in bytes without the high byte
; See program memory size in the device
datasheet.
.equ RAM_SIZE, 0x0600 ; Ram size in bytes
.equ EEPROM_SIZE, 0x0200 ; Eeprom size
config FOSCSEL, FNOSC_FRCPLL
config FOSC, FCKSM_CSDCMD & SOSCSEL_SOSCLP & POSCFREQ_MS & OSCIOFNC_OFF
config FWDT, FWDTEN_ON
config FPOR, MCLRE_ON & BORV_V18 & I2C1SEL_PRI & PWRTEN_ON & BOREN_BOR3
.equ PROCESSOR_IS_SELECTED, 1
.endif
.ifdef __24FV32KA302
.equ FLASH_SIZE, 0x5800 ; Flash size in bytes without the high byte
; See program memory size in the device
datasheet.
.equ RAM_SIZE, 0x0800 ; Ram size in bytes
.equ EEPROM_SIZE, 0x0200 ; Eeprom size
config FOSCSEL, FNOSC_FRCPLL & SOSCSRC_ANA & LPRCSEL_HP & IESO_ON
config FOSC, POSCMOD_NONE & FCKSM_CSDCMD & SOSCSEL_SOSCLP & POSCFREQ_MS
& OSCIOFNC_ON
config FWDT, FWDTEN_ON & WDTPS_PS32768 & FWPSA_PR128 & WINDIS_OFF
config FPOR, MCLRE_ON & BORV_V20 & I2C1SEL_PRI & PWRTEN_ON & BOREN_BOR3
& LVRCFG_OFF
config FICD, ICS_PGx2
.equ PROCESSOR_IS_SELECTED, 1
.endif
.if PROCESSOR_IS_SELECTED < 1
.error "Did not select one of our known processor configurations."
.endif
.equ FREQ_OSC, (8000000) ; Clock (Crystal) frequency (Hz)
---------------------------------------------------------------------
ff-pic24-30-33.s after line 827
---------------------------------------------------------------------
; ---------------------------------------------------------
; Addition to get UART1 working PIC24FV32KA302.
; PJ 2014-04-17
.ifdef __24FV32KA302
bclr ANSB, #ANSB2 ; want U1RX as digital on pin 6
; To work around silicon issue 5 for revision 4 chips.
bclr U1STA, #UTXISEL0
bclr U1STA, #UTXISEL1
; Still need to work around issue 4 by not sending more
; than three bytes at a time.
; Maybe some fix can be made in __U1TXInterrupt0:
; around line 361 in this file.
.else
; As Mike had it: interrupt when last character is shifted out
; of Transmit Shift Register.
.ifdecl UTXISEL1
bset U1STA, #UTXISEL0
.else
bset U1STA, #UTXISEL
.endif
.endif
; ---------------------------------------------------------
|
|
From: Mikael N. <mik...@pp...> - 2014-04-17 14:23:31
|
I don't really understand why the UART silicon bug would cause a problem with the current FF5.0 code. The TX interrupt routine only writes one character to the TX FIFO if the TXFIFO and TX shift register are empty. In addition XOFF chars are written without checking if the TX FIFO has any space. If the PC that sends to the PIC reacts slowly on the XOFF, FF will send XOFF for every character received from the PC. But this should not fill the TX FIFO since it has 4 empty places and the RX interrupts which may send XOFF occur at the same pace that characters are sent out. Did you experience any real problem? Does the UART TX loose any characters ? Are characters lost during flash write ? BR Mike On 04/17/2014 03:10 PM, Peter Jacobs wrote: > (b) The more troublesome issue is the UART silicon bug in my revision 4 > chips. There is a work-around of not completely filling the buffer but > I think that requires fiddling with the interrupt or queue code, which > is a bit beyond my capability at the moment. I added a little bit of > code to the main program, as shown below. > > |
|
From: Peter J. <pe...@me...> - 2014-04-17 22:23:27
|
Mike,
Yes
Yes
Don't know, but I don't think that the flash write is the problem.
Here is a transcript of some interaction. I should have included it
with the last note.
BPE Fahot I24 5.0
BPE Fahot I24 5.0
BPE Fahot I24 5.0
BPE Fahot I24 5.0
BPE Fahot ICt I24 5.0
ok<#rm>#rm
ok<#rm>#rm
2 3 * . 6 ok<,am<,a>
Characters are missing whenever a string is sent by the MCU. On the
last start-up message, you can also see out-of-order characters. I've
put a logic analyser on the pins and it looks consistent with the
picture of missing characters shown above (and there were no Xoff
characters in between).
I'm going to try a PIC24FV16KM202 (which fits the same minimal pin
layout) today and see if that behaves better.
Peter J.
On 18/04/14 00:23, Mikael Nordman wrote:
> I don't really understand why the UART silicon bug would cause a problem
> with
> the current FF5.0 code.
>
> The TX interrupt routine only writes one character to the TX FIFO
> if the TXFIFO and TX shift register are empty.
>
> In addition XOFF chars are written without checking if the TX FIFO has
> any space.
> If the PC that sends to the PIC
> reacts slowly on the XOFF, FF will send XOFF for every character
> received from the PC.
> But this should not fill the TX FIFO since it has 4 empty places and the
> RX interrupts
> which may send XOFF occur at the same pace that characters are sent out.
>
> Did you experience any real problem?
> Does the UART TX loose any characters ?
> Are characters lost during flash write ?
>
> BR Mike
>
> On 04/17/2014 03:10 PM, Peter Jacobs wrote:
>> (b) The more troublesome issue is the UART silicon bug in my revision 4
>> chips. There is a work-around of not completely filling the buffer but
>> I think that requires fiddling with the interrupt or queue code, which
>> is a bit beyond my capability at the moment. I added a little bit of
>> code to the main program, as shown below.
>>
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@pp...> - 2014-04-18 06:42:54
|
To verify that the UART errata is the problem
insert a 1 or 2 millisecond delay in EMIT.
EMIT:
mlit 2
rcall MS
rcall UEMIT
goto FEXECUTE
If it works, then it is clear that the UART TX interrupts cannot be
trusted on your chip.
This can also be used as a simple workaround.
I will also write polling TX routines that do not use interrupts.
It only checks the TRMT flag. I think that should work with the UART bug.
BR Mike
|
|
From: Peter J. <pe...@me...> - 2014-04-18 07:34:46
|
Yes, the delay works nicely. Nothing missed in the following transcript, I believe. Thank you. Peter J BPE FlashForth PIC24 5.0 2 3 * . 6 ok<#,ram> ok<#,ram> ok<#,ram> words true false Fcy dump allot .s words ms ticks r0 s0 latest rhere state bl rdrop endit next for repeat while again until begin else then if until, again, begin, else, then, if, not, nc, z, un, in, inline ['] ;i ; :noname : ] [ does> postpone create [char] ( char ' abort" ?abort ?abort? abort prompt quit >dp dp> .st inlined immediate shb interpret in? 'source >in tiu tib ti# number? >number sign? digit? find immed? (f) c>n n>c @+ c@+ place wmove cmove fill blanks erase word parse \ /string source base pad hp task ssave rsave ulink bin hex decimal hi d. ud. . u.r u. sign #> #s # >digit <# hold up min max ?negate tuck nip ud/mod ud* / */ */mod u*/mod u/ * u> u< d> > d< < d= = <> within +! ." ," s" (s") type >pr .id accept 1 0 umax umin spaces space cr 2dup 2drop 2! 2@ chars char+ cells cell+ aligned align cell c, , here dp ram eeprom flash xa> >xa pfl 2constant constant co: 2variablevariable >body to is defer value user mod /mod u/mod sm/rem um/mod m* um* s>d p++ p2+ p+ pc! p! pc@ p@ @p r>p !p>r !p d0< 0< d0= 0= d2/ 2/ d2* 2* 2- 1- 2+ 1+ ?dnegate dnegate negate dinvert invert xor or and d- - d+ m+ + dabs abs r@ r> >r rot over swap drop rp0 rp@ sp@ sp! (d) (c) exit @ex execute dup rx1? rx1 tx1? tx1 u1rxq u1txq cq: cq0 cq>? cq> >cq? >cq 'key? 'key 'emit key? key emit scan skip n= rshift lshift btst bclr bset mtst mclr mset c@ @ c! ! u1- u1+ fl- fl+ iflush cf, as, cf@ cf! btss, btsc, btst, bset, bclr, as0 bra, retfie, return, rcall, operator ei di i] [i aivt ivt int! cwd pause turnkey warm empty load busy idle a> >a literal marker ok<#,ram> On 18/04/14 16:42, Mikael Nordman wrote: > To verify that the UART errata is the problem > insert a 1 or 2 millisecond delay in EMIT. > > EMIT: > mlit 2 > rcall MS > rcall UEMIT > goto FEXECUTE > > If it works, then it is clear that the UART TX interrupts cannot be > trusted on your chip. > > This can also be used as a simple workaround. > > I will also write polling TX routines that do not use interrupts. > It only checks the TRMT flag. I think that should work with the UART bug. > > BR Mike > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@pp...> - 2014-04-18 20:48:23
|
Peter, I just pushed a FlashForth without UART TX buffering. Could you test how it works ? BR Mike |
|
From: Peter J. <pe...@me...> - 2014-04-19 03:41:01
|
It works very nicely, thank you Mike. The PIC24FV32KA302 rev 4 chip transmits reliably only with the unbuffered option. The PIC24FV16KM202 works with the default buffered option, however, I've had to make a small edit to the include ff30.inc file to get the assembler to include the p24f16ka_config file. Surprisingly to me, this KM chip seems to be assigned to the __PIC24F family by the assembler. The most changes went into the p24f16ka_config file so that I could select the different chips via the MPLABX project properties, however, these don't amount to much. There are also another couple of small edits needed to the main ff-pic24-30-33.s file to accommodate these chips. I've put a complete copy of my current work tree at http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24fv32ka-apr-2014.tar.gz if you would like to pick the changes out. Alternatively, should I make a patch against your git repository? I'm still doing something wrong with the PLL, but that is for another day. The unbuffered TX option allows me to continue at the moment. Cheers, Peter J. On 19/04/14 06:48, Mikael Nordman wrote: > Peter, > I just pushed a FlashForth without UART TX buffering. > > Could you test how it works ? > > BR Mike > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > 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