Jump to content

Something very strange using DC-brick and bricklib!


Recommended Posts

  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:




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.





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();



    // USBD_Write does not always call callback when USBD_STATUS_SUCCESS

    // Wait for NUM_SEND_TRIES

    if(num_tries > usb_num_send_tries) {


        send_status = 0;

        return 0;





Link to comment
Share on other sites

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.



Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...