Jump to content
  • 0

MCC 118 DAQ HAT Incorrect Response


James7

Question

Hi, I've come across a problem where an MCC 118 hat will always fail to start a scan, returning with an 'Incorrect response' error. This occurs when both using my own code and running the example single_value_read.py. daqhats_read_eeproms detects the board's address correctly, as does daqhats_list_boards, however it does list both the Firmware and Bootloader version as 0.00. 

Up until recently, it's been working perfectly fine, however now I'm completely unable to read anything from it. Any troubleshooting guidance would be appreciated, however the raspberry pi in question is remote, and I don't currently have physical access to it. 

image.png.4b149e31e167dbdf9df414ca5ab6bfd2.pngimage.thumb.png.fe6d45b0d392d8af753dc0383f944aaf.png

Edited by James7
Adding further images
Link to comment
Share on other sites

15 answers to this question

Recommended Posts

  • 0

Try: 

sudo daqhats_read_eeproms

followed by:

daqhats_list_boards

Upgrade the firmware with the following commands:

mcc172_firmware_update 0 ~/daqhats/tools/MCC_172.fw

mcc172_firmware_update 1 ~/daqhats/tools/MCC_172.fw

mcc118_firmware_update 2 ~/daqhats/tools/MCC_118.hex

after, test each board with the MCC DAQ HAT Manager utility. (located in your Raspberry PI->Accessories.

best regards,

John

Link to comment
Share on other sites

  • 0

Hi, thanks for the response. sudo daqhats_read_eeproms and daqhats_list_boards both returned as shown in the screenshots attached. daqhats_read_eeproms seems to return as normal, and daqhats_list_boards recognises the MCC 118, however the versions are listed as 0.00. Finally, the firmware updates on the two 172s returned as expected, however for the 118, it failed with an 'Error entering the bootloader' as shown in the screenshot attached.

As for the MCC DAQ HAT Manager utility, the PI is running the lite version of Raspbian, so only command line available sadly. Is there any way to access this from the command line?

image.thumb.png.8a2c4d6c2f5a8157bf2fd11be08c1ed2.pngimage.thumb.png.b46ed5230192dc534927929f69bf12d6.pngimage.thumb.png.0ca19cb1b2e80abc7476a28460fc4dc3.png

Link to comment
Share on other sites

  • 0

Hello,

I don't believe this is the problem but better safe than sorry. Jump into Raspberry PI->Preferences->RaspBerry PI Configuration. Click the Interfaces tab and make SPI and I2C are enabled. Otherwise, if the board is less than a year old and it is in the United States, I can issue an RMA number for a replacement. [requires the return of the old board]

Best regards,

John

Link to comment
Share on other sites

  • 0

Hi again, I can confirm that both SPI and I2C are enabled. Is there really nothing else that can be done at this stage, or is it well and truly dead to the world? If so, is there any way of know what might have caused it?

Thanks,

James

Link to comment
Share on other sites

  • 0

The microprocessor is not responding, that why you get a 0.00 for the firmware version. If you had the system in your hands, you could reduce it to just the MCC 118 at address 0 to see if one of the other boards is stepping on it. 

Best regards,

John

Link to comment
Share on other sites

  • 0

Ah I see what you mean. Pretty sure I can guess the answer, but I'm guessing there's no way of programmatically reinitialising the hat, or I suppose forcing a software update? But yeah, I suppose there's not much I can do until I can physically check the Pi itself.

On a separate note, do you know what might have caused something like this? I've got another pi in a similar setup, so I'd like to take some precautions on that one if I can. 

Thanks again,

James

Edited by James7
Added second paragraph question
Link to comment
Share on other sites

  • 0

Hi John,

I've had another thought on this subject. Is it possible that the code used to read from the MCC 118's sensor could have killed it? I suspect this is not the case given what you've said, but the code was recently modified to increase the scan rate of the sensor, as well as how often it is read by (from every 15 mins to every 1 min). I still suspect the voltage spikes over this, but could it have affected things?

Thanks,

James

Link to comment
Share on other sites

  • 0

Hey James,

Program code will not damage the board. However, the 118 micro could have corrupted firmware if they ran the firmware updater with the wrong file. If this happened, power off the RPi and short pins 3 & 4 on the 5-pin W3 connector and fire it back up. [There's no W3 connector per say, just the trace holes in the PCB.] This may force it into the bootloader. Update the firmware, remove power, remove the short and fire it back up. Read the EEPROMs and list the devices. If it's your lucky day, it will show up functioning normally.

Good luck,
John

Link to comment
Share on other sites

  • 0

Hello,

Now I wanted to check the firmware version after trying the two troubleshooting options, and now I get a firmware of 1.03 and a bootloader version of 1.01, so it worked, but I can't tell how and why. At least now it works.

Best,

Anna

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...