ChibiOS Free Embedded RTOS

Posted: **Wed May 15, 2013 2:31 pm**

Hello,

I'm using the STM32VL Discovery for a school project.
We want to run chibios on this board. We chose the stable version 2.4.3. To test if it works and to make debugging easy we want to use the UART/SERIAL driver to put some feedback data on the terminal on our pc.

Now the problem is, there is no correct data showing up.

The serial driver is started as follows:

Code: Select all

sdStart(&SD1, NULL);

If i'm correct the settings are 38400 - 8 - N - 1 by default.

Then, to test if the serial driver works, the following code is used:

Code: Select all

sdPut(&SD1, "t");

or

Code: Select all

chprintf((BaseChannel*)&SD2, "test");

There is no character 't' printed at the display neither the text 'test'.

even the STM32VL Discovery demo doesn't work properly. When the test is started after reset, there is only garbage on the terminal window.

Are we doing something wrong? Or maybe the clock frequency isn't correct.

Stellaris

Posted: **Wed May 15, 2013 2:41 pm**

Hi,

The comm parameters are those you posted. Is the levels translator doing its job? it could be just an electrical issue.

Giovanni

Posted: **Wed May 15, 2013 3:11 pm**

Make sure that you don't just set the settings as you listed them yourself but also disable the flowcontrol.

~ Tectu

Posted: **Wed May 22, 2013 12:20 pm**

Thank you, we used another level translator the next day and it just worked. It was just an electrical issue.

I have another question. We are communicating via spi with a wireless module. The module generates an interrupt when data is received or when data is ready to be transmitted. I have initialized the EXT driver, and it reacts on an interrupt. In this interrupt callback function, an interrupt handler for the wireless module is called. In this handler, an interrupt register is readed over spi, and the intterupt status is saved in a temporary variable. But after sending the register address to the module, the spiSend function doesn't return, and the receive function isn't called. It looks like the whole os is frozen.

The interrupt pin is connected to GPIOC 6. An interrupt is generated on the falling edge.
The following code is the configuration of the EXT driver:

Code: Select all

static const EXTConfig extcfg = {
  {
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_FALLING_EDGE | EXT_CH_MODE_AUTOSTART, extcb1},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
   {EXT_CH_MODE_DISABLED, NULL},
  },
  EXT_MODE_EXTI(0,
                0,
                0,
                0,
                0,
                0,
                EXT_MODE_GPIOC,
                0,
                0,
                0,
                0,
                0,
                0,
                0,
                0,
                0)
};

The callback function extcb1 is shown below:

Code: Select all

static void extcb1(EXTDriver *extp, expchannel_t channel)
{
  (void)extp;
  (void)channel;

  palSetPad(GPIOC, 9); // led on
  chSysLockFromIsr();
  mrf_interrupt_handler(&SPID2);
  chSysUnlockFromIsr();
}

The spi read function is shown below:

Code: Select all

uint8_t mrf_read_short (SPIDriver *spip, uint8_t address)
{
  uint8_t receive;
  uint8_t send = (address<<1 & 0b01111110);

  spiSelect (spip);

  spiSend (spip, 1, &send);

  palClearPad(GPIOC, 9); // led off

  spiReceive (spip, 1, &receive);

  spiUnselect (spip);

  return receive;
}

The led is not turned off in the mrf_read_short function, so the function spiSend wont return. Am i doing something wrong here?

Stellaris

EDIT:

I attached an image of the logic analyzer I used.

Posted: **Wed May 22, 2013 4:00 pm**

Hi,

The code is not complete so I am assuming you are calling spiSend() and spiReceive() from the callback.

A callback is called from the context of an ISR, this means you can call only I-class functions from there. spiSend() is:
1) A synchronous function that suspends the invoking thread, you cannot suspend an ISR.
2) Not I-class.

The correct approach is to call spiStartSendI() instead which is:
1) Asynchronous, the function starts the transfer and returns immediately.
2) I-class.

Note that spiStartSendI() signals the end of the transfer with another callback where you can call spiUnselect() and finish the operation.

This kind of errors is caught by the state checker, you can enable it in chconf.h. It is recommended to use the debug options during development.

Note that things like I-class are described in the "kernel concepts" chapter in the documentation.

Alternatively you can wakeup a thread from the EXT callback and perform the SPI operation from the thread using synchronous functions.

Giovanni

Posted: **Wed May 22, 2013 6:56 pm**

Hello Giovanni,

I implemented all wireless operations in a single thread. The ext driver sets a flag and the thread is checking that flag every 1ms. The basic transmitting and receiving is working now.

Thank you.

Stellaris

Posted: **Wed May 22, 2013 7:36 pm**

Hi,

You can wakeup the thread from the callback without have to poll a flag (saving CPU time). There is a variety of ways to do this, for example you could initialize a semaphore to zero:

Code: Select all

chSemInit(&sem, 0);

In the thread wait on the semaphore:

Code: Select all

chSemWait(&sem);

reset to zero the semaphore from the callback in order to wakeup the thread:

Code: Select all

chSysLockFromIsr();
chSemResetI(&sem, 0);
chSysUnlockFromIsr();

Giovanni

ChibiOS Free Embedded RTOS

STM32VL Discovery serial problem

STM32VL Discovery serial problem

Re: STM32VL Discovery serial problem

Re: STM32VL Discovery serial problem

Re: STM32VL Discovery serial problem

Re: STM32VL Discovery serial problem

Re: STM32VL Discovery serial problem

Re: STM32VL Discovery serial problem