sietse

Hello,

Don't ask me why, but I tried again, and now both bricks work with

jtag debugging. (there we no errors/warnings earlier)

Sorry to bother you,

  regards,

    Sietse

  Hello List,

I did remove the DISABLE_JTAG_ON_STARTUP, but the problem remains the same.

Using a master brick instead of the DC brick DOES work however.

So, what else could be the problem, apart from hardware?

The DC brick works OK for the rest.

  Thanks in advance,

    Sietse

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

  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;

    }

  .....

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

Hello list,

I try to use the jtag interface of the debug brick with a Olimex ARM-USB-OCD-H interface and openocd, but the dc brick is not recognized.

Openocd gives:

    ......

Error: JTAG scan chain interrogation failed: all ones

Error: Check JTAG interface, timings, target power, etc.

Error: Trying to use configured scan chain anyway...

Error: sam3.cpu: IR capture error; saw 0x0f not 0x01

    ......

Is there anything wrong? Has anyone used the jtag interface?

  Regards,

      Sietse