Is this code with rdfast secure?

Christof Eb.

Hi,
I have narrowed crashes down to using the following routine, which is part of TAQOZ to find the length of a NULL terminated sring. It executes from COG memory. Adress is given in register a and the length is also returned in a.

00818 07b fc780023 STRLEN                    rdfast  #0,a
0081c 07c f6044600                                   mov     a,#0
00820 07d fd781e10 .L0                     rfbyte  x wcz                ' read a byte
00824 07e 1b8c47fe         if_nc_and_nz    ijnz    a,#.L0               ' continue while not 0 or not >$7F'
00828 07f fd64002d                      ret

Is it possible, that sometimes the streamer is not yet filled properly, when rfbyte executes?
In the P2 docu there ist: "For RDFAST modes, it is necessary to do a RDFAST sometime beforehand, to ensure that the hub RAM FIFO is ready to deliver data."
What means sometime?
I have replaced the routine with a much slower version in Forth and this avoids the crashes.

Thanks for any hints!
Christof

Wuerfel_21

Yes, this is perfectly ok, because D to RDFAST is #0. That means it will stall until the FIFO is ready.

Also, what do you mean by "crash"? The function as given will always return at some point. Even if some of the read bytes were theoretically corrupted, it will still eventually find a zero byte (since there's a 512k block of unmapped memory)

Perhaps likely: something is corrupting your cog ram and that leads to all sorts of funnies.

Christof Eb.

Crash means:
The routine, which uses the result will go into a very long loop. It is the FOR of a for next loop which does handle a 0 as 2^32 repeats.
The strlength routine seems to either oversee the end Zero or to report a wrong zero length.

The code is also secure for interrupts? The serial input service routine sits in hub ram which should activate the streamer for it?

Wuerfel_21

Of course, if you got an interrupt changing the FIFO state, that won't work.

evanh

The bug is probably elsewhere. Make sure you're up to date on Flexspin compiler.
If the streamer is unexpectedly active, that'd be stealing the FIFO data. Try adding XSTOP before the RDFAST.

evanh

PS: The term "sometime beforehand" means at any time prior. There is no time limit. As long as the FIFO is setup with the RDFAST ahead of using it with RFBYTE then it'll fetch the desired data from hubRAM. Of course that also means the FIFO can be holding stale data if that block of hubRAM gets changed in the interim.

Christof Eb.

Thanks for your input!
In my special case in the editor, that I am writing, the strlen and then For sequence is used very often, if you move the cursor. 2000 times per char of movement. Then the serial int occures also frequently. So you can produce the crash within a minute or so.

evanh

@"Christof Eb." said:
... The serial input service routine sits in hub ram which should activate the streamer for it?

Activates the FIFO, yes. A jump to hubRAM is an implicit RDFAST (Hubexec begins). Which shouldn't cause any issues. It takes care of itself. The only thing you can do wrong is also explicitly issue a RDFAST during Hubexec. This would change the FIFO's fetching address and crash Hubexec.

evanh

@"Christof Eb." said:
... the strlen and then For sequence is used very often, if you move the cursor. 2000 times per char of movement. Then the serial int occures also frequently. So you can produce the crash within a minute or so.

Ah, of course, the opposite problem to what I was considering. Hubexec is changing the FIFO part way through the string length loop. You probably need to move the ISR code into cog space. Either lutRAM or cogRAM. That way it won't be issuing the implicit RDFAST on each IRQ.

Or do like you've done already and stop using the FIFO for Strlen function.