Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Hardware & Devices
  4. No data on MISO from ADAS1000

No data on MISO from ADAS1000

Scheduled Pinned Locked Moved Hardware & Devices
helphtmlcomtutorialquestion
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Member 10035290
    wrote on last edited by
    #1

    I am currently using a dsPIC33FJ128MC802 [^] on a DM300027[^] (starter) board to read data from the ADAS1000[^] evaluation board (for ECG) via the J4 SPI pins. I have the SPI pins (SCLK, MOSI, MISO and CS) of both boards connected correctly according to the ADAS1k documentation. I am having trouble getting the two (ADAS1k and dsPIC) to talk to each other. I set up the uProc's SPI and then tried to configure the ADAS1k by sending based on an example in the ADAS1000 documentation. These commands should configure the ADAS1k to send out a 150Hz Test Tone Sine Wave on each channel. The MOSI is enveloped by a CS, and it is sent as 4 bytes, for example 0x8500000B is sent as 0x85 followe[]d by 0x00, 0x00, 0x0B. To read data on the MISO, the SPI sends out four 0x00 bytes to generate clock signals for the MISO. Writing 0x55555555 followed by 0xAAAAAAAA shows a signal on the MISO, which looks like a 0x0050. I haven't been able to get signals on MISO in other cases. I tried writing to a register and reading it back after a few ms delay, but nothing showed up on the MISO. I've captured the scope of the SPI (MOSI, SCLK and CS) signals on both boards and they seem to be fine. The MOSI signal seems as expected. I'm still unable to see anything on MISO though. Any suggestions on what else I can do to troubleshoot this issue? Thank you.

    J 1 Reply Last reply
    0
    • M Member 10035290

      I am currently using a dsPIC33FJ128MC802 [^] on a DM300027[^] (starter) board to read data from the ADAS1000[^] evaluation board (for ECG) via the J4 SPI pins. I have the SPI pins (SCLK, MOSI, MISO and CS) of both boards connected correctly according to the ADAS1k documentation. I am having trouble getting the two (ADAS1k and dsPIC) to talk to each other. I set up the uProc's SPI and then tried to configure the ADAS1k by sending based on an example in the ADAS1000 documentation. These commands should configure the ADAS1k to send out a 150Hz Test Tone Sine Wave on each channel. The MOSI is enveloped by a CS, and it is sent as 4 bytes, for example 0x8500000B is sent as 0x85 followe[]d by 0x00, 0x00, 0x0B. To read data on the MISO, the SPI sends out four 0x00 bytes to generate clock signals for the MISO. Writing 0x55555555 followed by 0xAAAAAAAA shows a signal on the MISO, which looks like a 0x0050. I haven't been able to get signals on MISO in other cases. I tried writing to a register and reading it back after a few ms delay, but nothing showed up on the MISO. I've captured the scope of the SPI (MOSI, SCLK and CS) signals on both boards and they seem to be fine. The MOSI signal seems as expected. I'm still unable to see anything on MISO though. Any suggestions on what else I can do to troubleshoot this issue? Thank you.

      J Offline
      J Offline
      Jonathan Davies
      wrote on last edited by
      #2

      Based on sorting out other busses e.g. I2C, CAN I'd recommend: Build in, or use, some logging facility to record what's happening on each chip, even if its only a count or letter stored to show where you're code is going. Use a USB to SPI converter or something you know works to prove each work individually - it's much easier when one end is a 'known' rather than with and 'unknown' at each end of the wire. Read the manuals on the chips and on the SPI bus - I know it's obvious, but chip manuals tend to focus on how the chip works - not on the bus. Get the manual on the bus protocol. Have someone else look at it and show them, OK perhaps you wouldn't be posting here if you could do that but it really helps. I saw someone debug for days without turning power on to a stepper motor he was trying to step. Try and scope the interaction signals, and work through them, after all there should show exactly what's happening: which chip is not responding or signalling as expected. Don't handle just the happy path, handle the error cases as well - e.g. set timeouts and set sone code to log if the time out occurs even if its just to log what the error was.

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups