Hi Robert,

 

Thanks for the insights, and of course while the group was off the air for a while

I'm pretty near getting on top of it.

It turns out it's not the INTs that are causing this after all.

As you might know, this is to do with the BASIC interpeter, and I can execute

Basic that prints data really fast with no problems at all.

Also, when I just loop really fast in a printf() with a long string, it works good

as gold too.

It's when I use one specific procedure call that I've narrowed it down to.

I think it's a CG issue, but not sure, it's very hard to track down :-(

It might be my interpreter code too, but I doubt it.

 

Maybe to clarify a bit :

> Not really related to your actual problem but since you are using printf
> why bother with a transmit interrupt?  Unless you are planning on
> multithreading?  I've always found that all a serial transmit interrupt on
> single threaded apps does is introduce needless complexity (read bugs).

There's a few very specific reasons it's set up that way.

That UART channel normally carries ASCII data, and then of course no INTs

would be needed, given that it's a human I/F. However, when I will add the RF

frontend it is very important to have these INTs, for example you can give a

Connect statement to the interpeter, and that immediately sets up a TDD session

between 2 nodes, so I need to carry binary protocols along, and I can't afford to

waste CPU time on polling. (the polling loop on tx_chars dropping down is temporary

of course. I find it's a good test to see if everything is up to scratch, obviously

something's not :-)

 

The large (sort of) buffer is the minimum needed to create a pseudo-full

duplex RS232 wireless link between 2 nodes. While data is being serviced on

the RF in one direction, the other side's RS232 RX buffer can fill up, and compensate

for the Half Duplex nature and Line Turn Around delays.

When it's in Binary mode, the scheme above isn't used, the buffer is filled up,

and then the INTs are enabled, so the CPU can spend most of its time doing other

things. RTS/CTS is used there.

And yes, afterwards my own small but fast RTOS will be plugged back in, so I'll use

counting semaphores to handle the ring buffers.

 

> That raises a bunch of design issues to mind.  Why such a large gap?  Why
> not add to buffer as soon as any room is available?  And finally why two
> different variables to keep track of the room in the ring buffer?

Partially as above, the large gap is there to reduce CPU loading, if too much data

is being written too fast into the ring buffer.

I find using a Head and a Tail more convenient to manage, rather than having to

reset the pointer all the time, it's also easier to do the ground work w/o the RTOS,

but have the whole system built up so it's easy to assign tasks and only change the

"foreground" code, then _actually_ being foreground code instead of some sort of

a superloop. The dead CPU time is then being used better. I'm trying to optimise

what will be in what task, and minimise # of tasks, because many full featured OSs

reschedule as slow as buggery. Latency issues galore then.

 

 

> I don't see how that could happen given your outline.  The pointer is
> updated exactly once, as is the count.  One possibility is that there is an
> access control problem.
>
> Are your pointers and counters declared as volatile?

Of course.

 

> Is access to both protected with interrupt disabling and re-enabling sequences?

That's a good idea, but I know now that's not where this specific problem is.

It's very repeatable with differing Basic application programs, so I doubt it's

just that.

It's mainly really that a CG problem with context switch threw me out

 

> One thing that can happen on the ARM that won't on micros with small
> register sets is that the pointer and counters can be held in the register
> sets and won't get spilled out to memory unless they are declared as
> volatile.  I'd expect the issue to be a little more dramatic in that case
> but...
>
> This does 'feel' more like an access control race where the interrupt
> decrements the counter and returns to normal execution which immediately
> overwrites it with an old updated value.  Something like:
>
> r1 = tx_chars
>                          - jump to transmit interrupt
>                          - Save appropriate registers
>                          - Perform transmit
>                          - r1 = tx_chars
>                          - r1 -= 1
>                          - tx_chars = r1
>                          - restore saved registers
>                          - return from interrupt
> r1 += 1
> tx_chars = r1
>
> And now tx_chars is one higher than it should be.  As bugs go these ones
> tend to be very timing sensitive.
>
> Ring any bells?

 

That's a very good point you make Robert.

I will make sure TX INTs are disabled when I modify tx_chars.

I've had it sitting there dumping data out while executing Basic for hours, and it ran

with no problems, whereas a specific Basic program caused it to hang in that "loop"

within 30-40 secs at the most.

It must be a library call somewhere that messes up something.

I'll certainly keep you posted.

 

B regards,

Kris

 

Hi Robert,

 

Well you were certainly dean on the money.

It's not completely solved yet, and I do know there is a context

switch issue as well, but these are my findings so far :

 

> OK, I see what you are after here.  Makes sense.  Most of the serial work
> I've done has had serial as a low priority compared to the rest of the code
> (It's more important for the machine to run than for it to communicate text
> to someone).  That being the case it would only poll during dead time
> anyway.  I have done CAN and other network machine comms where that wasn't
> the case though.

The RF normally runs at 64 kBps, and the RX INT is a state machine that looks for

preamble, checks the Frame sync header, handles all DLL stuff, including CRC on-the-fly.

It is very important that I don't have overruns. If a char is lost, then the FHSS stuffs up etc.

That puts already quite a bit of demand on RTIOS, as the time spent in the Kernel cannot

be more than just under 2 chars at 64 kBps, or ~ 312 uS.

That was quite a bit of a challenge on MSP430, especially for auto-event handling and

timers.

On ARM it's much more relaxed, but I'm quite new to it.

 

> I have seen that sort of behaviour with access control issues.  Changing
> unrelated code changes the observed behaviour.  The messiest I've run into
> was a problem with a third party RTOS that took some time to find (mostly
> because of chip bugs).  The problem ended up being a sequence that worked
> only if compiler optimization was on above a certain level.  Amazingly
> enough the RTOS company claimed it wasn't a bug (and had no intention of
> changing it) since it worked fine with optimization on!

The UART operation on LPC2000 is still confusing wrt the TX FIFO.

The UM states that THRE asserts when 2 or more chars are in the FIFO, but then

somewhere else it states that each char asserts it.

That would have explained why I always had a char too many, because the FIFO

only INTs with 2 or more chars on THRE. If that were the case then I'm barking up

the wrong tree with my THRE Handler.

I find the User's manual too vague about it, maybe it's because it's supposed to be

16C550. I've never really programmed PCs and I never want to, so I'm not used

to these UARTs.

If someone can clarify a bit better what the hell the deal is exactly with the TX FIFO,

I'd be grateful. I've googled around on 16C550 till I'm silly, but not much luck

finding a description how exactly the TX FIFO works. Is it a FIFO between THR and

the actual Shift register ? That's my interpretation, but then you still get the same

amount of TX interrupts anyway, just that they're spaced together in time a lot more,

with more gap in between.

I don't see the point, or maybe I just don't get it. The RX, fair enough, that is great

having a FIFO there.

 

I turned optimisation off, and inserted a write of 0x01 to UOIER before I handle

the buffer or pointer, so THRE interrupt is disabled.

When I started it, the code resets itself in no time.

It's obvious that indeed an atomic operation is needed. I didn't expect that.

And you're dead right about the timing issues, optimisations affect how fast the

execution is, hence the asynchronous timing effect on each other, and that confused

me.

 

Never had such bloody headaches with this sort of thing.

What a pain.

 

Now it's pretty much fixed, except that running code still "resets" itself.

I can't work out what's getting trashed where.

I _should_ work now, there are no other coding issues wrt multiple access,

but it doesn't.

 

Oh, well I'll be off the streets for a bit.

 

> Uggh, wild pointer or library re-enabling interrupts or ...   Good luck.

I'm gonna need it !

 

All the best,

Kris