Messages

61

µTasker general / Re: How to use the UART to get data and send data!

« on: August 19, 2010, 10:55:53 AM »

Email me if you have any questions, I use serial ports quite a bit (Mostly with the uTasker Modbus module, which is VERY good).

Good luck Martin

62

MODBUS / Re: What are the Hardware Timer Requirements for the Modbus Module

« on: August 18, 2010, 06:17:32 PM »

Yes, I've just found that section about the SYSTICK so I think I'm Lucky , Just have to make sure I don't need any more timers.

I will give the idea of using one timer for all modbus timing some thought as it might provide a more scalable solution.

Cheers

Martin

63

Luminary Micro ^TM LM3SXXXX / Re: Code hitting irq_hard_fault(void)

« on: August 18, 2010, 05:58:55 PM »

Hi Mark,

Interesting thought, maybe the think to do is to put an Idle timer in the startup code that will wait for 1 - 2 secs in a loop at powerup, if you are in debug mode. This way the chip would not do anything (not enable any peripherals etc).

Its not the biggest thing on my list at the moment just a frustration.

Regards

Martin

64

MODBUS / What are the Hardware Timer Requirements for the Modbus Module

« on: August 18, 2010, 05:33:16 PM »

Hi Mark,

What are the Hardware timer requirements for the Modbus module? I'm using Luminary Micro LM3S1968 chips with Modus RTU half duplex RS485 running at 115200 baud.

I think I've pretty much answered my own question, I've just found the section on Hardware timers in the modbus manual

I need to support 4 x Modbus serial channels, 3 using the the LM3S1968 built-in UARTS and one using an external SPI uart, probably the SC16IS7xx mentioned here http://www.utasker.com/forum/index.php?topic=998.0

From my reading of the Modbus source code each Modbus serial channel requires a hardware timer, for RTS timing? The chip contains 4 x Timers with one I presume being used for the timer tick, so theoretically I have 3 timers left which should be enough. Is my understanding correct. The SC16IS7xx as you know handles RTS control automatically. It maybe that I still need timers 4 timers as I need 1.5 and 3.5 character timers for all 4 channels.

I was also wondering if it was possible to do everything with just one hardware timer, that could be set to just interrupt for the shortest period required? It would make the timer interupt handler more complex but more flexible

Cheers

Martin

65

µTasker general / How to use NUMBER_EXTERNAL_SERIAL

« on: August 16, 2010, 03:28:21 PM »

Hi Mark,

I have an application where I need more Uarts that are on my chip, I'm using an LM3S1968 processor which has 3 Uarts and I need 4.

I notice that you may have dealt with this same problem youself because the Simulator has the define NUMBER_EXTERNAL_SERIAL which seems to allow the simulator to handle another 4 Com channels. I notice that these is no target code presumably because there are many ways of adding extra Uarts.

I have two options,

1. To bitbang a UART using GPIO and a couple of timers, possibly basing code on AN01270-01 from http://www.luminarymicro.com/home/app_notes.html

2. To use an external SPI or IIC uart like the MAX3107 http://www.maxim-ic.com/datasheet/index.mvp/id/6463

Which ever solution I use I want to hook in to uTasker so the application interface is the same, I presume I would need to do the following.

1. Extend fnConfigSCI to handle configuring my extra Uarts
2. Handle filling up RX buffers from my own, interupt routines.
3. Handle emptying TX buffers, and transmitting characters.

Am I correct im my assumptions and do you have any pointers?

Thanks

MArtin

66

Luminary Micro ^TM LM3SXXXX / Re: Fixing an IIC lockup with SDA held low

« on: August 05, 2010, 08:01:01 PM »

Well its partially working, the concept works but I can't just re-initialise my IIC task and re-run 

fnOpen( TYPE_IIC, FOR_I_O, &tIICParameters);

I don't think the drivers were ever coded to be  restarted. If I try re-initialising the task then the software crashes, I'm presuming its because IICPortID is not getting allocated properly.

Next I tried going a bit deeper and running fnConfigIIC(&tIICParameters); this improved things. But code is still not starting back up again cleanly, and the application resrats soon after. I'm suspecting some buffers need to be cleared.

When I detect IIC lockup, (done via a timeout counter) I run this bit of code

      {
      fnKickSCL();                           // Clock the SCL line 16 times to free up SDA
      fnConfigIIC(&tIICParameters);   // Init IIC hardware
      IICIdle = true;                        // Reset my internal flag that flags if a transmission is in progress
      }

Where fnKickSCL() is defined below

void fnKickSCL(void)
{
    int i;
   int delay;
   #define IICDELAYTIME 10

   _CONFIG_PORT_OUTPUT(B, PORT_BIT2);
   _CONFIG_PORT_INPUT_PULLUP(B, PORT_BIT3);
   
   for(i=0; i<16; i++)
   {
      for(delay=0; delay<IICDELAYTIME; delay++) _CLEARBITS(B, PORT_BIT2);
      for(delay=0; delay<IICDELAYTIME; delay++) _SETBITS(B, PORT_BIT2);
   }
}

This is now at least restarting the IIC Bus as can be seen in the attached logic trace, I've got to find out where the software error is.

How do I go about resetting the IIC buffers, I don't mind about loosing data?

Cheers

Martin

67

Luminary Micro ^TM LM3SXXXX / Code hitting irq_hard_fault(void)

« on: August 05, 2010, 06:07:07 PM »

Hi Mark,

Just after a bit of advice, I'm using Rowley crossworks V1.7b22 and have an application, that seems to have problems running with the JTAG.

If I build the code as "Bare minimum bootloader" it works fine with the bootloader.
If I build it using the Rowley command "Build and Debug" in either "THUMB Flash Debug" or "THUMB Flash Release" modes it hits irq_hard_fault and thats it.
If I build it using the Rowley command "Build and Run" it builds but does not run (maybe it locks up as above) but if you press the reset switch it runs.

I can get arround this by building then resetting the board then attaching the debugger, but this operation is different to all the other projects I've created.

When I hit the irq_hard_fault loop the call stack does not show anything helpful, just irq_hard_fault.

Any pointers that might help me?

Cheers

Martin

68

Luminary Micro ^TM LM3SXXXX / Fixing an IIC lockup with SDA held low

« on: August 05, 2010, 03:15:18 PM »

Hi Mark,

We've it a problem where a noise spike can cause the IIC bus to lockup the condition is described here on a TI website here http://processors.wiki.ti.com/index.php/I2C_Tips

The problem is described below

A problematic scenario can arise if the processor/I2C module gets reset while it is in the middle of mastering a transfer. In this scenario the external slave might be holding SDA low to transmit a 0 (or ACK). In this case it will not release SDA until it gets another falling edge on SCL. Even in this case it's not until it tries to transmit a '1' that it will actually release SDA after seeing SCL fall. The end result is that the bus will hang. If the I2C tries to initiate a new transfer it will hit an "arbitration lost" condition because SDA won't match the address it's sending. There are a couple ways to recover from this scenario.

Option 1: For devices that mux the SCL/SDA pins with GPIO, the easiest thing is to configure the pins for GPIO operation and toggle SCL until the slave releases SDA. At this point you should be able to resume normal operation.

Option 2: Many devices don't mux SCL/SDA with GPIO since the I2C I/O cells are often special open drain cells. A workaround has been reported to work even on these devices. By configuring the I2C for "free data format" and then reading a byte the I2C will immediately start sending clocks to input data (rather than trying to send an address). This can be used to free up the bus.


I.m not sure what "free data format" is, so it seems like the solution is to trap the condition and to switch the SCL line back to GPIO then toggle it a nuber of times (say 16) to get out of this state. Then restart the IIC bus. This poses a number of questions

1. Looking at the Port configration Marcro's it looks like they are not configured for selecting a GPIO function after they have been used for a pheripheral. (They don't access the GPIOAFSEL_x registers) I suggest adding GPIOAFSEL_##ref &= ~(pins); as shown below.

2. Looking at the code below, why is the statement SRCR2 &= ~CGC_GPIO##ref; repeated? is this a typo or for timing reasons.

3. If I reinitialise the IIC using fnConfigIIC can you forsee any problems?

4. How do I detect the problem in the first pace, as the IIC module does not report errors (I guess I could try reading a register which I know to ge a fixed value and if I see 0xff then assume an error)

Code: [Select]

// Port macros
//
// Configure pins as output, including enabling power and digital use. eg. _CONFIG_PORT_OUTPUT(A, PORTA_BIT0);
//
#define _CONFIG_PORT_OUTPUT(ref, pins)  RCGC2 |= CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; \
GPIOAFSEL_##ref &= ~(pins); GPIODEN_##ref |= (pins); GPIODIR_##ref |= (pins); _SIM_PORT()
// Configure pins as input, including enabling power and digital use. eg. _CONFIG_PORT_INPUT(B, PORTB_BIT2);
//
#define _CONFIG_PORT_INPUT(ref, pins)   RCGC2 |= CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; \
GPIOAFSEL_##ref &= ~(pins); GPIODEN_##ref |= (pins); GPIODIR_##ref &= ~(pins); _SIM_PORT()

// Configure Pullups and Pulldowns
#define _CONFIG_PORT_PULLUP(ref, pins)   GPIOPUR_##ref |= (pins); _SIM_PORT()
#define _CONFIG_PORT_PULLDN(ref, pins)   GPIOPDR_##ref |= (pins); _SIM_PORT()
#define _CONFIG_PORT_INPUT_PULLUP(ref, pins)   RCGC2 |= CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; \
GPIOAFSEL_##ref &= ~(pins); GPIODEN_##ref |= (pins); \
GPIODIR_##ref &= ~(pins); GPIOPUR_##ref |= (pins); _SIM_PORT()
#define _CONFIG_PORT_INPUT_PULLDN(ref, pins)   RCGC2 |= CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; SRCR2 &= ~CGC_GPIO##ref; \
GPIOAFSEL_##ref &= ~(pins); GPIODEN_##ref |= (pins); \
GPIODIR_##ref &= ~(pins); GPIOPDR_##ref |= (pins); _SIM_PORT()


69

µTasker general / Re: UART and simulator

« on: August 05, 2010, 03:06:38 PM »

Hi Rad,

I get that warning too, don't worry about it its to do with SD card access and doesn't seem to cause a problem.

The rebuilding problem with VS2008 seems to be liked to it not realising that C++ files need to be rebuilt if header files change.

For testing took at com0com to give you virtual null modem serial ports see this post http://www.utasker.com/forum/index.php?topic=54.msg4258#msg4258

Cheers

Martin

70

MODBUS / Modbus Timeout Error

« on: July 29, 2010, 03:56:10 PM »

Hi Mark,

Just thought I'd let you know about a "feature" I'd found in the modbus module, and thought you might want to mention in the Modbus manual.

I have a modbus system running and was trying to tighten up the timeout delay because my targets reply very quickly. I accidentally set the modbus timeout value in the cMODBUS_default in modbis_app.c to the same value as the uTasker TICK_RESOLUTION. This was then causing random suprious comms timeouts, which took some while to trace. I was getting timeouts even when valid data was returned.

Just something to be aware of in the Modbus module, I don't think there is anyway arround this as by definition the resolution of the system is defined by the TICK_RESOLUTION

Cheers

Martin

71

ATMEL^TM AT91SAM7X and AVR32 / Re: EVK1105 PERIODIC Software Timer

« on: July 28, 2010, 10:11:03 AM »

Hi Mark,

I just wanted to clarify this for other users at it was not immediatly obvious from the documentation when I started with uTasker.

I think you mean above

It will only remain in polling mode when no periodic value to set (i.e. 0). Therefore your understanding is correct.

72

ATMEL^TM AT91SAM7X and AVR32 / Re: EVK1105 PERIODIC Software Timer

« on: July 27, 2010, 03:48:43 PM »

Hi Mark,

Just to clarify my understanding and that of others, if a Task has a state of UTASKER_GO it will run in polled mode, if its period time in the ctTaskTable is set to 0 or NO_DELAY_RESERVE_MONO i.e. it will be run every time the it is checked in the sheduling loop.

But if it has a period set to a value in the ctTaskTable then it will instead run at this periodic rate.

const UTASKTABLEINIT ctTaskTable[] = {
  // task name,  task routine,   input queue size, start delay, period, initial task state
  { "Wdog",      fnTaskWatchdog, NO_QUE,      0, (DELAY_LIMIT)( 0.2 * SEC ),  UTASKER_GO},      // watchdog task (runs immediately and then periodically)
  { "M-Menu",    fnMenuTask,    MEDIUM_QUE,  0, (DELAY_LIMIT)( 0.125 * SEC ), UTASKER_GO},  //

Cheers

Martin

73

µTasker general / Re: USB host support planned ?

« on: July 24, 2010, 02:10:58 AM »

PS. I believe that there are some USB peripheralsthat can communicate with a processor via UART or SPI and take over the USB host interface and mass storage class - possibly including file system too(?). Such a device may also be a method of quite simply adding such functionality to a project.

One part that Mark might be thinking about is the Vinculum from FTDI http://www.ftdichip.com/FTProducts.htm#Vinculum

74

NXP^TM M522XX, KINETIS and i.MX RT / Re: Changing default telnet port number

« on: July 23, 2010, 11:57:44 AM »

Search for fnStartTelnet in the utasker project, in the uTasker demo this is in debug.c in the function fnConfigureTelnetServer

The first parameter to fnStartTelnet is the port number.

        Telnet_socket = fnStartTelnet(temp_pars->temp_parameters.usTelnetPort, (2*60), 0, 0, fnTELNETListener);   // 2 minute inactivity timeout

You can see that the port is pulled from the parameters.

Looking at the Parameter definition in application.c you can see

const PARS cParameters = {
    PARAMETER_BLOCK_VERSION,                                             // version number for parameter validity control
    (unsigned short)(2*60),                                              // default telnet_timeout - 2 minutes
    (CHAR_8 + NO_PARITY + ONE_STOP + USE_XON_OFF + CHAR_MODE),           // {43} serial interface settings
    23,                                                                  // TELNET port number

So the port number is defined here, just change this to which ever port you want, I've just changed it to 223 on my test setup and it worked as expected.

Cheers

Martin

75

Luminary Micro ^TM LM3SXXXX / New Luminary compiler IDE

« on: June 22, 2010, 06:27:59 PM »

Hi Everyone,

I've just come across this site http://atollic.com/index.php/download/truestudiostellaris which provides another IDE for developing for the Luminary Chips, looks like its Eclipse based but not sure if it uses GCC.

Not sure on prices but it looks like the lite version is free

See this other post for more IDE's http://www.utasker.com/forum/index.php?topic=864.msg3818#msg3818

I've not had a chance to try this yet, but I thought it might be of interest to people, escpecially as it supports JTAG debug via the Luminary JTAG adapters.

Cheers

Martin

Update:
I've also found this site http://www.coocox.org/Index.html again not tested anything but just making people aware of it.