Dear list,

 

I have something very strange when using bricklib software with a DC-brick.

Something that actually should not happen at all!

 

We are creating a Simulink (matlab) target using DCBrick, so that we can

use this brick natively in Simulink.

To do that we have to create special software that interfaces with Simulink,

using the Embedder Coder product of Mathworks.

 

Therefore we use the DC-brick directly, only using bricklib that interfaces to the

Simulink software.

In our current test version, not using Simulink yet, we only communicate between

DC-brick and PC. We only use the leds, usb and the serial port.

 

The bricklib code is changed in a few places, because we do not use free_rtos.

I don't think this is a problem, also because the original Atmel software is able

cope with this.

The test software is a simple loop that only uses usb_send and usb_recv.

  (The usb and serial software from bricklib is interrupt driven.)

 

Now for the strange bit.

=======================

 

The routine "usb_send" from bricklib/com/usb/usb.c starts the write, and then

waits for a callback to signal its completion.

 

The callback is called, indicating the data has been send, the send_status is set correctly,

but the while loop in usb_send DOES NOT SEE this change!

So after many retries it returns a 0, see the code fragment below.

I think this actually CANNOT happen! (the loop is executed many times!)

 

But it gets stranger.

If I insert some basic I/O in the while loop, it DOES work.

For example insertin reading a arbitrary I/O pin e.g. using:

  PIO_Get(&unused_pin);

 

Questions:

1  How can the correct setting of send_status in the callback routine, verified by

  using a printf, NOT be seen in the while loop?

2  And also, how can reading some I/O-pin make a difference?

 

I am completely at a loss here, hopefully somebody can enlighten me.

  Regards,

      Sietse

 

===============================================================================================

Here the relevant fragments of the usb_send function:

 

  ....

    if(USBD_Write(IN_EP, data, length, usb_send_callback, (void*)usb_sequence_number) != USBD_STATUS_SUCCESS) {

  ....

    uint32_t num_tries = 0;

    while(~send_status & USB_CALLBACK) {

      // no free_rtos, so removed  taskYIELD();

 

      num_tries++;

    // USBD_Write does not always call callback when USBD_STATUS_SUCCESS

    // Wait for NUM_SEND_TRIES

    if(num_tries > usb_num_send_tries) {

        usb_sequence_number++;

        send_status = 0;

        return 0;

    }

  .....

=================================================================================================

 

Must be an error in the compiler, the comparision is probably removed as an optimization. The compiler didn't recognize the interrupt routine that sets the state and thought that the while condition is always true.

 

What gcc version are you using?

 

Have you tried making send_status volatile?

Thanks for the quick replay, Making send_status volatile did it.

I explicitly thought about this and assumed gcc would know this.

But maybe the use of a callback that is dynamically set is too difficult for gcc.

I use version

      arm-none-eabi-gcc (Sourcery CodeBench Lite 2012.03-56) 4.6.3

Thanks again.

  Sietse