• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 1721 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM437x IDK USB device driver issue

Aaron Kellner
Intellectual 740 points

Other Parts Discussed in Thread: AM4379

Hi;

   I have the AM4379 IDK. Right now when I plug it in to the usb PORT on the PC running windows 7, the OS gives me an error claiming that the device driver can't install because it is unrecognized. This happened only just today as I have been working with these devices for a while now. I have 2 cards and they both do the exact same thing. What could the problem be. Has windows updated to a different driver? I didn't permit anything like this to occur. Does anyone have any clues?

  • 0
    TI__Guru**** 393215 points
    Hi,

    Have you tried on another PC or a different USB port?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 740 points

    Hi Biser;

        Turned out the USB cable that came in the Mistral box didn't work!?! I used a different one and it all worked fine.

    Can I return the faulty cable?

    Aaron

  • 0 in reply to Aaron Kellner
    TI__Guru**** 393215 points
    I cannot help on this. You will need to contact the vendor where you bought the units.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 740 points

    Hi Biser;

       Hoping you can shed some light on this. As you know I am trying to work the BiSS firmware up into a real interface to an external system. In order to do that I must get the AM4379 to react to the interrupt from the PRU when new messages are ready for xfer. To debug that architecture, I am using a simple timer firmware that has an interrupt call in it taken from one of the Linux examples (PRU_Timer_Interrupt). I can use the BiSS GEL files from the BiSS driver example to load this firmware and with the timer at its Max delay it will run the PRU for ~21 seconds and halt as expected after presumably firing the interrupt. The problem is that when I run the driver program I've written that uses calls to the SYS_BIOS_DRIVER lib to do the exact same operations in exactly the same order as the GEL scripts, The PRU clock never runs so no timer delay occurs and the PRU suspends at the HALT immediately. Even if I run the driver to the point where it loads the PRU code then I use the script to start the PRU, I get the same results. The firmware jumps to the HALT and suspends as if the PRU clock never started. What is the GEL load doing that I am not doing with the driver?

    Thanks for any clues,

    Aaron