NQ port behaviour differs between Simulator and Target Board

[marcelo_]

Hi Mark
I nearly completed my proof of concept ( RC, by now  )
All development was done in the simulator - great job !
Today I flashed it to M52259DEMO board; near all features are working as expected; the exceptions are
1) I'm testing input recognition using NQ port, bits 1 and 5, because they are wired to the board's switches. When in the simulator, I toggle any of them and the software can "read" the change. But when running in the board, it seems that the pushes on the switches are not recognized. What may be wrong, Mark?
2) I can ping the board, uploaded via ftp the html pages, and can connect with a browser, all exactly like in the simulator. But when trying to connect via telnet, after some little time the telnet client comes up with "Connection to host lost." message. Where  could I need to look?

TIA

Marcelo

[mark]

Hi Marcelo

1) The NQ ports default to IRQ lines. When in IRQ mode their inputs need to be read using the EPPDR0 register (EPPDR1 for IRQ8..15, if available).
I think that the simulator updates the PORTIN_SETNQ register. This is correct when set as GPIO but not when left as IRQ lines.
I will need to see whether this can be improved, but you should be able to solve the issue on the target by reading the EPPDRx register instead.

2) TELNET problems on the target are usually due to a lack of RAM available on the heap. Check the memory state before trying to establish the TELNET connection to see how much HEAP is available. The TELNET socket allocates a buffer of TCP_BUFFER length the first time that is used. (TCP_BUFFER is typically configured to 2800 bytes). If the heap doesn't have this space you can reduce the buffer size or increase heap setting. In the second case ensure that there is enough stack space - it should never go to 0. There are several discussions about this with more details - eg: http://www.utasker.com/forum/index.php?topic=486.msg1926#msg1926

Note that the exact use of memory varies between the simulator and the target and there is tuning value in config.h called MEM_FACTOR. If this is set so that the simulator and target have the same free HEAP it helps catch such problems in the simulator. Generally the simulator just has enough memory but the target just fails...

Regards

Mark

[marcelo_]

Hi Mark
Thank you.
Where and what could I change to disable the association between the NQ ports and the IRQ?
My proof of concept requires that any input port could be polled, simmetrically.
TIA
Marcelo

[mark]

Hi Marcelo

PNQPAR defaults to 0x4444, meaning that IQR1, IRQ3, IRQ7 and IRQ7 are IRQ inputs.
To set these to GPIO do:

PNQPAR &= ~(CLEAR_FUNCTION_Q_BIT_1 | CLEAR_FUNCTION_Q_BIT_3 | CLEAR_FUNCTION_Q_BIT_5 | CLEAR_FUNCTION_Q_BIT_7);
(or just the inputs inputs to be changed)

Alternatively the macro
_CLEAR_FUNCTION(NQ, (CLEAR_FUNCTION_Q_BIT_1 | CLEAR_FUNCTION_Q_BIT_3 | CLEAR_FUNCTION_Q_BIT_5 | CLEAR_FUNCTION_Q_BIT_7));
does the same.

After this you can read the port by reading PORTIN_SETNQ.
Generally the macro _READ_PORT(NQ) does the same.
To read masked bits of the port the macro
_READ_PORT_MASK(NQ, (PORT_NQ_BIT1 | PORT_NQ_BIT5))
is equivalent to (PORTIN_SETNQ & (PORT_NQ_BIT1 | PORT_NQ_BIT5))

Try to use the port macros where possible since they allow simplified portability (also some processors allow port masking, for example, to be performed more efficiently and this is automatically be included in the macro).

Regards

Mark

[marcelo_]

Thank you very much, Mark

Marcelo

[marcelo_]

Hi Mark
It's me again.
You told me to set

PNQPAR &= ~(CLEAR_FUNCTION_Q_BIT_1 | CLEAR_FUNCTION_Q_BIT_3 | CLEAR_FUNCTION_Q_BIT_5 | CLEAR_FUNCTION_Q_BIT_7);
(or just the inputs inputs to be changed)

Alternatively the macro
_CLEAR_FUNCTION(NQ, (CLEAR_FUNCTION_Q_BIT_1 | CLEAR_FUNCTION_Q_BIT_3 | CLEAR_FUNCTION_Q_BIT_5 | CLEAR_FUNCTION_Q_BIT_7));
does the same.

I was seeking where to put that code but could not find the best place.
Would you be so kind and advice me where to put these lines?

TIA

Marcelo

[mark]

Hi Marcelo

I tend to put such initialisations in the routine fnUserHWInit() [in application.c].

This is called very early on during initialisation and is useful for setting up HW configurations/port settings which will be used by the project so that they are ready before the tasks start their work.

Regards

Mark

[marcelo_]

Thank you again, Mark!