Messages

136

Luminary Micro ^TM LM3SXXXX / Re: Problems trying to Read using IIC

« on: June 05, 2009, 09:34:57 PM »

Hi Mark,

I applied your modifications and it has improved things, I seem to be reading the correct number of bytes now, but I’m still got the following problems.

1.   Single byte reads are still broken.
2.   Reads of the PCF8575 chip, triggered from another task cause the IIC bus to lock up.

I've attached a document describing my findings in more detail. I'll also email you my current project and the logic trace taken with DigiView (I've sent you traces before so I assume you can still view them)

Cheers

Martin

137

Luminary Micro ^TM LM3SXXXX / Re: Problems trying to Read using IIC

« on: June 04, 2009, 06:03:35 PM »

Thanks, Mark for the quick reply.

I'll do some more investigation tomorrow to see if I can help find the problem

Cheers

Martin

138

Luminary Micro ^TM LM3SXXXX / Problems trying to Read using IIC

« on: June 04, 2009, 01:23:20 PM »

Hi Mark,

I'm trying to debug some IIC problems. My Hardware has two IIC devices a TC665 Fan controller and a PCF8575 16 bit IO expander, I've added these chips to the Simulator and it all seems to work fine. On the real hardware I have been testing the integrity of the IIC by changing the FAN speed in response to a button push. Using the following Commands

static const unsigned char IIC_WrTC665_FanSlow[] = {0x36, 0x06, 0x00};            // {address, register, data}
static const unsigned char IIC_WrTC665_FanFast[] = {0x36, 0x06, 0x0f};            // {address, register, data}
static const unsigned char IIC_WrTC665_FanSpeed[] = {0x36, 0x07};            // {address, register, data}
static const unsigned char IIC_RdTC665_FanSpeed[] = {2, 0x37, OWN_TASK};            // {address, register, data}
static const unsigned char IIC_Rd8575[] = {2, 0x41, OWN_TASK};            // {bytes, address, TASK_TO_WAKE}
static const unsigned char IIC_Rd8575_1[] = {1, 0x41, OWN_TASK};            // {bytes, address, TASK_TO_WAKE}
static const unsigned char IIC_Rd8575_2[] = {2, 0x41, OWN_TASK};            // {bytes, address, TASK_TO_WAKE}
static const unsigned char IIC_Rd8575_3[] = {3, 0x41, OWN_TASK};            // {bytes, address, TASK_TO_WAKE}
      

I start the IIC interface using the following

static void fnConfigIIC_Interface(void)
{
    IICTABLE tIICParameters;

    tIICParameters.Channel = 0;
    tIICParameters.usSpeed = 100;                                        // 100k
    tIICParameters.Rx_tx_sizes.TxQueueSize = 64;                         // transmit queue size
    tIICParameters.Rx_tx_sizes.RxQueueSize = 64;                         // receive queue size
    tIICParameters.Task_to_wake = 0;                                     // no wake on transmission

    if ((IICPortID = fnOpen( TYPE_IIC, FOR_I_O, &tIICParameters)) !=0) { // open the channel with defined configurations
   fnWrite(IICPortID, (unsigned char *)&IIC_WrTC665_FanSlow, sizeof(IIC_WrTC665_FanSlow)); // set the fan speed
        fnRead(IICPortID, (unsigned char *)&IIC_Rd8575, 0);            // start the read process of 16 bytes
    }
}

I get a write to the Fan as expected, followed by a read from the 8575 chip, but a logic analyser shows 3 bytes being read not 2 as expected.

I can write as much as I want to the Fan chip, but as soon as I try another read of the 8575 chip using fnRead(IICPortID, (unsigned char *)&IIC_Rd8575, 0); only one byte is returned and the IIC bus seems to lock up.

I've documented my findings in the attached document, which has the logic analyser traces.

It seems that uTasker is trying to read 1 more byte than requested, and that only reading 1 byte seems to lockup the IIC driver.

Do you have any thoughts?

Cheers

Martin

139

Luminary Micro ^TM LM3SXXXX / Re: Luminary Micro acquired by Texas Instruments

« on: May 15, 2009, 10:27:02 AM »

Typically hot off the mark, Mark (No pun intended).

Interesting news, which I hope is good news for Luminary, it will hopefully give them more muscle to compete with the big boys like NXP.

The more I use the Luminary chips the more I like them.

Martin

140

NXP^TM LPC2XXX and LPC17XX / Re: LPC2388 & KSZ8721 10Mbit problem

« on: April 27, 2009, 11:58:49 AM »

Hi

You could always try this mailing list, http://www.sics.se/~adam/uip/index.php/Mailing_list

The uTasker TCPIP stack is NOT UIP it is much more powerful, Also remember UIP is free where as uTasker requires a license to be purchased.

Are you asking if uTasker works on the Olimex board at 10M?

Regards

Martin

141

µTasker general / Re: uTasker Replacements for Standard C String functions

« on: April 20, 2009, 05:45:46 PM »

Hi Mark,

I know my example looked a bit silly at the beginning, concatenating two strings and adding a space. I was just demonstrating having to decrement the pointer.

Your modifications improve things and make the use of the string functions less error prone. You are right linking in printf / sprintf etc often link in large chunks of code. I will incorporate them.

I presume defining STRING_OPTIMISATION will break the demo applications and they will need slight reworking.

One thought fnDebugDec() and fnDebugHex() and fnBufferHex() take different parameters, would it be worth renaming fnDebugDec() as fnBufferDec() and making fnDebugDec() work more like fnDebugHex()? It just makes things a bit cleaner, I expected the two debug functions to take the same parameters. The other option is to loose fnBufferHex() and make fnDebugHex() work like fnDebugDec(). Just a thought, I know this would require slight re-working of the demo application, but as you are planning to add STRING_OPTIMISATION this might be the ideal time to do it.

extern CHAR *fnDebugDec(signed long slNumberToConvert, unsigned char ucStyle, CHAR *ptrBuf)
extern CHAR *fnBufferHex(unsigned long ulValue, unsigned char ucLen, CHAR *pBuf)
extern void fnDebugHex(unsigned long ulValue, unsigned char uLen)        // display hex value

In your final example, you reduced the code to

Code: [Select]

char cDisplayStr[40];     
unsigned int uiDecNumber = 123;
unsigned int uiHexNumber = 0xa5;
char *cPtr;       
cPtr = fnDebugDec(uiDecNumber, NO_TERMINATOR, uStrcpy(cDisplayStr, "Part1Part2 ")); // Add a number in DECIMAL format to string
*cPtr++ = '*'; // Add * character to string
cPtr = fnBufferHex(uiHexNumber, (2 | WITH_LEADIN | NO_TERMINATOR), cPtr); // Add a number in HEX format to string, precede with 0x and display 4 hex digits
*cPtr++ = ':';

Would you not need to add an extra *cPtr++ = 0; to the end to ensure that the string is null terminated?

Cheers

Martin

142

µTasker general / Re: How to change MAC address?

« on: April 16, 2009, 04:33:19 PM »

Hi Aaron,

In the simulator the file FLASH_LM3SXXXX.ini represents the flash memory of the chip being simulated just delete this file and its like you have erased the chip.

I'm simulating the Luminary micro LM3S6965 hence the name of my ini file, this ini file is in the same folder as the Visual C project file.

Cheers

Martin

143

µTasker general / uTasker Replacements for Standard C String functions

« on: April 16, 2009, 12:31:59 PM »

Hi Mark,

In the spirit of uTasker I've investigated the use of uStrcpy and fnDebugDec and fnBufferHex to remove the need for sprintf to concatinate strings.

I've searched the forum and the manuals for information but dis not find anything, so I've worked it out (I think).

Code: [Select]


static char cDisplayStr[40];     // not sure if this needs to be static or if pointer passed ??
unsigned int uiDecNumber = 123;
unsigned int uiHexNumber = 0xa5;
char *cPtr;
               
cPtr = uStrcpy(cDisplayStr, "Part1");
cPtr = uStrcpy(--cPtr, "Part2"); // decrement cPtr to loose null at end of string
cPtr--;                                                      // Loose Null from end of string
*cPtr++ = ' '; // Add space character to string
cPtr = fnDebugDec(uiDecNumber, 0, --cPtr); // Add a number in DECIMAL format to string
*cPtr++ = '*'; // Add * character to string
cPtr = fnBufferHex(uiHexNumber, (2 | WITH_LEADIN | NO_TERMINATOR), cPtr); // Add a number in HEX format to string, precede with 0x and display 4 hex digits
*cPtr++ = ':'; // Terminate String with : character

Would be the same as             

Code: [Select]

static char cDisplayStr[40];     // not sure if this needs to be static or if pointer passed ??
unsigned int uiDecNumber = 123;
unsigned int uiHexNumber = 0xa5;

sprintf(cDisplayStr, "Part1Part2 %d*%x:", uiDecNumber, uiHexNumber);

Does this make sense, you have to be careful as some functions add terminating nulls and some don't.

Please let me know if there is an easier way to do the above,

Cheers

Martin

144

Luminary Micro ^TM LM3SXXXX / IO port access in uTasker

« on: March 06, 2009, 01:16:03 AM »

Hi Mark,

Is there a standard way to access / configure IO ports in uTasker, I have noticed some functions in debug.c like fnSetPort and fnInitialisePorts but cannot find any documentation on them. Should I modify these or have you defined a standard set of functions within uTasker for I/O port coonfiguration and access?

Cheers

Martin

145

Luminary Micro ^TM LM3SXXXX / Re: Problems Downloading and Debugging uTasker within Rowley Crossworks

« on: February 27, 2009, 04:44:39 PM »

After some lengthly off list discussions between myself Mark and Rowley these issues have now been resolved, for the benefit of other readers I'll explain the problems below and the solutions we found. I've also attached a  corrected Rowley project file to this post for the main uTasker project. Once I've tested it I'll also post one for the bare minimum bootloader. Just ensure that you are using the lastest SP3 of the utasker project and replace the project file with the one contained in this post.

It should also be noted that my problems related to the downloading and debugging of files within the Rowley IDE. The Binary files produced by Rowley have always been correct and have not changed.

NOTE if you are reading this and there is a later SP avaliable for the Luminary Micros then these fixes will have already been incorporated into the project files by Mark. DO NOT USE THE ATTACHED PROJECT FILES as they may be out of date.

ALso you will need to upgrade your Version of Rowley Crossworks to at least V1.7build17 as a bug was found in the Rowley debugger.

Right here are the problems and the fixes.

1. Firmware would not Download to Target from within Crosworks
The problem was that the firmware loader was missing from the project file, so Rowley didn't know how to download to target flash. In the project properties for each target configuration the target option "Loader File Path" needed to be set to "$(StudioDir)/targets/Luminary_LM3S/Release/Loader.elf"

2. Target would not Reset correctly
The problem was that Rowley had no reset script defined. In the project properties for each target configuration the target option "Reset Script" needed to be set to "RAMReset()" for RAM builds and "FLASHReset()" for FLASH builds.

3. Could not set Breakpoints in the Debugger
The problem was that the Rowley debugging system could not handle there being no start-up assembler code. There was a cludgy code fix but the easiest solution is to upgrade Crossworks to version 1.7build17 or greater.

3. Setting a breakpoint on startup
Not a major thing but to get the code to pause on startup for Debug builds, you need to go to "Tools > Options > Debugging > Breakpoint options" and change the initial beakpoint setting to _main 

I hope this helps other readers, and thanks again to Mark for some fantastic support.

Cheers

Martin Honeywill

146

Luminary Micro ^TM LM3SXXXX / Re: Using The Srial Port in uTasker

« on: February 24, 2009, 09:42:47 PM »

Hi Mark,

#ifdef SERIAL_INTERFACE

appears in lots of files should I also change it to

#if defined SERIAL_INTERFACE && defined DEMO_UART

in the following files

webinterface.c (3 times)
application.c  (9 times)
debug.c (15 times)


I think I should not change it in

app_hw_lm3sxxxx.h
tty_drv.c
driver.c
LM3sxxx.c

I've tried the above and it seems to work, the debug menu appears on the Telnet port.

I think the above would be a good modification to make to the project, so you would have to define DEMO_UART to force the debug menu to appear on the serial port, otherwise it would appear on the Telnet port.

I added the following

extern void fnMyFirstTask(TTASKTABLE *ptrTaskTable)
{
  static unsigned char ucCounter = 0;
 
  fnDebugMsg("Hello, World! Test number ");
  fnDebugDec(ucCounter++, 0, 0);
  fnDebugMsg("\r\n");
}

And added

  { "xmytask!!", fnMyFirstTask,  NO_QUE,    (DELAY_LIMIT)(5 * SEC), (DELAY_LIMIT)(2 * SEC), UTASKER_STOP}, // my first task (runs after a delay of 5s and then periodically every 2s)

to the ctTaskTable definition in TaskConfig.h

and also added

extern void fnMyFirstTask(TTASKTABLE *ptrTaskTable); // prototype

to TaskConfig.h

Now I also get "Hello, World! Test number nn" printed to the Telnet port so debug printf seems to work also, I've just left the menu in for the moment.

I've detailed what I've done above so others might find it easier to follow.

Cheers

Martin

147

Luminary Micro ^TM LM3SXXXX / Re: Using The Bootloader with Luminary Micro Chips

« on: February 24, 2009, 03:46:19 PM »

I've just reconnected to the utasker via ftp, and the file "z_Upload.bin" is no longer shown in the listing so maybe my previous worries were unfounded? Does utasker delete z_Upload.bin when it has finished with it?

Martin

148

Luminary Micro ^TM LM3SXXXX / Using The Serial Port in uTasker

« on: February 24, 2009, 03:04:28 PM »

Hi Mark,

I'm evaluating various sections of the uTasker project, and I'm now looking at the serial ports.

I would like to use all three ports on an LM3S6965 for my own use,

Port 1 - connected via USB serial chip to a PC (115200baud)
Port 2 - connected via half duplex RS485 to a modbus device (115200baud)
Port 3 - Connected full duplex to a Crystalfontz RS232 display (19200baud)

I'm a bit confused how to setup the serial ports, what I don't want is to have the demo telnet menu apearing on one of the ports.

What I want to do is have all tree serial ports free for me to use, and debug output redirected via the Telnet interface, I like the idea of "debug printf's" going via Telnet. And lastly I don't want the normal Telnet menu at all.

What defines do I need to do the above?

Cheers

Martin

149

Luminary Micro ^TM LM3SXXXX / Using The Bootloader with Luminary Micro Chips

« on: February 24, 2009, 02:41:46 PM »

Hi Mark,

I've just tested the boot loader, and worked out how to use it. I downloaded the generated "z_Upload.bin" file by ftp. And rebooted and the new software was flashed and verified to be running.

I then connected via ftp again and say the "z_Upload.bin" file, does this mean the next time the board is rebooted it will flash the code again? or is the file flagged some how as being used. Does the user need to delete this file from the file system?

Under the server option in FileZilla you can enter custom FTP commands, this would be a great way to handle an addition "RESET" command that would force a reboot and reprogram of the target, without having to do a power down.

Cheers

Martin

150

µTasker general / Re: Using TCP in the uTasker project

« on: February 24, 2009, 12:36:13 AM »

Mark,

I've just used the demo code at the head of this post to test how to handle TCP and I found a number of typo's, I'm mentioning them here so you can amend the code listing so others don't have the same problems I did. The errors are as follows

1. The Code below has an extra }

    case TCP_EVENT_CLOSED:
        fnTCP_Listen(Socket, ++usTestPort, 0);                    // go back to listening state on next port number
        break;
        }
 
should be
   
    case TCP_EVENT_CLOSED:
        fnTCP_Listen(Socket, ++usTestPort, 0);                    // go back to listening state on next port number
        break;


2. In the following code test_message->tTCP_Header should be test_message.tTCP_Header
   
    case TCP_EVENT_DATA:
        if ((ucEvent == TCP_EVENT_REGENERATE) || (!uMemcmp((CHAR*)ucIp_Data, "TEST" , 4))) {
            uStrcpy((CHAR*)test_message.ucTCP_Message, "Hi!!");
            if (fnSendTCP(Socket, (unsigned char *)&test_message->tTCP_Header, 4, TCP_FLAG_PUSH) > 0) {
                return APP_SENT_DATA;
            }
        }

    should be

    case TCP_EVENT_DATA:
        if ((ucEvent == TCP_EVENT_REGENERATE) || (!uMemcmp((CHAR*)ucIp_Data, "TEST" , 4))) {
            uStrcpy((CHAR*)test_message.ucTCP_Message, "Hi!!");
            if (fnSendTCP(Socket, (unsigned char *)&test_message.tTCP_Header, 4, TCP_FLAG_PUSH) > 0) {
                return APP_SENT_DATA;
            }
        }

3. In the start-up code you suggest using
    USOCKET Test_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)10, fnTestListener);
    This should be
    USOCKET Test_socket = fnGetTCP_socket(TOS_MINIMISE_DELAY, (unsigned short)10, fnTestListener);
    Note the lowercase s in fnGetTCP_socket

Looking at tcpip.h it seems the case of the function words after a _ symbol is a bit random, for example

extern USOCKET fnGetTCP_Socket(unsigned char ucTos, unsigned short usIdleTimeout, int (*listener)(USOCKET, unsigned char, unsigned char *, unsigned short) );
extern USOCKET fnGetUDP_socket(unsigned char ucTOS, int (*fnListener)(USOCKET, unsigned char, unsigned char *, unsigned short, unsigned char *, unsigned short), unsigned char ucOpts);
extern USOCKET fnReleaseUDP_socket(USOCKET SocketHandle);
extern USOCKET fnReleaseTCP_Socket(USOCKET TCPSocket);

I hope the above helps

Cheers

Martin