Unhandled exception utasker1.3 for NE64

[lthyagar]

Now I am getting Unhandled exception at 0x0045018f in uTaskerV1-3.exe: 0xC0000005: Access violation writing location 0x00000069.
error at line:  tx_control[pars->Channel]->opn_mode = pars->usConfig;
Any hints will be appreciated.
Thanks!!
Lav

[mark]

Hi Lav

This looks as though the value of
tx_control[pars->Channel]
is 0.
What value is pars->Channel?
It should be 0 (not '0') as in the case of the UART/COM port mapping.

Regards

Mark

[lthyagar]

Hello Mark,

tInterfaceParameters.usConfig = (CHAR_8 | NO_PARITY | ONE_STOP | NO_HANDSHAKE |  CHAR_MODE );
tInterfaceParameters.Channel = SERIAL_PORT_0;
#define SERIAL_PORT_0  '1'  ( in ascii because of no extended serial support).
hence pars->Channel is '1 '
Some more debug info:
QUEbuffer = CXX0030: Error: expression cannot be evaluated
buf_length = CXX0030: Error: expression cannot be evaluated

Thanks!!
Lav

[mark]

Hi Lav

#define SERIAL_PORT_0  '1'  ( in ascii because of no extended serial support).
This is a define for use by the simulator. It maps the UART 0 to COM1.

You must not use this as tInterfaceParameters.Channel value.
tInterfaceParameters.Channel  is the physical UART in the device. In the case of the NE64 0 or 1 only.

You thus need:

tInterfaceParameters.Channel = 0;
and
#define SERIAL_PORT_0  '1'

Regards

Mark

PS. Using tInterfaceParameters.Channel = SERIAL_PORT_0;
means that you are trying to open UART 0x30, which doesn't exist.

[lthyagar]

Hello Mark, appreciate your help. I have got UART 1 on the NE64 to work.
But I had to comment out "return DriverID" in tty_drv.c. This was causing UART 1 to communicate at 19200.  The code was not going to fnConfigSCI(pars->Channel, pars);   hence not picking up
the new baud rate from my code.

 if (NO_ID_ALLOCATED != (DriverID = fnSearchID (entry_add, pars->Channel))) {
        if (!(driver_mode & MODIFY_CONFIG)) {
     //       return DriverID;                                             // channel already configured
        }

After running for a while I get this error:
Run-Time Check Failure #2 - Stack around the variable 'ol' was corrupted.

I had got my GPS code to run on the SAM7x project without any issues. I am using the character LCD in the (4x16) mode.
Now I am having problems getting the same GPS code to work in the NE64 code base. The LCD is not being updated as per my code refresh rate( 4 event timers at 0.1 seconds). The third line in the LCD is going to the second and the fourth to the third.
My code is a new task(gps task) and is completely independent of the processor architecture. It used the function  fnDoLCD.. to send messages to the LCD task.

Thanks!!
Lav

[mark]

Hi Lav

It sounds as though the UART 1 is being opened twice in the project, otherwise it wouldn't get to
if (!(driver_mode & MODIFY_CONFIG)) {

If this is the case (and wanted), the caller can set
fnOpen( TYPE_TTY, MODIFY_CONFIG, &tInterfaceParameters )
rather than
fnOpen( TYPE_TTY, FOR_I_O, &tInterfaceParameters )
and this should avoid the need to change the TTY code.

The run-time error is VS telling you that the stack (presumably in the routine fnCheckRx()) was corrupted between the routine being started and exiting. I don't think that I have heard of this before, but it wouldn't show up with VS6.0 since it doesn't do the stack checking. VS6.0 was used exclusively to develop the NE64 project.

I also can't comment on the LCD difficulty. The LCD code is the same between the NE64 and SAM7X packages but there have been a number of simulator improvements between the two. This is possibly a bug in the NE64 simulator but again I haven't had reports of this particular case.

I am however wondering why you have chosen to use the NE64? The uTasker NE64 project has not been further developed for about 2 years now and is not recommended for new designs. The device was interesting in 2004 when it first came out but essentially died when Freescale introduced the Coldfire M5223X. The Coldfire is vastly more powerful and easier to use, with much more memory, more and better peripherals, and even costs less than the NE64. [For NE64 based products it can almost be placed on the old NE64 footprint and be used - there are only a few quite small modifications required].

Unless there is a very important reason for using the NE64 I would switch to a Coldfire V2: http://www.utasker.com/forum/index.php?topic=256.0
The Coldfire project is available as V1.4 and will almost certainly be compatible with any SAM7X project code too - both in the simulator and on the target.

Regards

Mark