Bosch Shared
- Top Results
See all results
- About RichT
- About RichT
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
About RichT
since
10-28-2020
11-12-2020
RichT
Member
11
Posts
1
Likes
0
Solutions
11-06-2020
06:52 PM
After checking your trace I could see the main problem was that we were not sending the register id at the start of each separate firmware "packet". We had some other internal errors but this was the main one regarding the firmware upload. I think this was partly because the description in the datasheet in section 5.2.1 item 7 says not to resend the firmware upload id which I took to include not sending the reg address and the firmware length. I would suggest that this is changed to clarify the reg address should still be sent. Also in the data sheet section 5.2.1 there is no mention of being able to transmit data in the way you have in your trace - this section only describes TX burst transfer which is why we spent so much time thinking this problem was caused because we had added in repeat starts between firmware data sections. This is a reasonable assumption for us to make because there are many devices out there that only accept burst tx transfer. I would recommend clarififying this fully in section 5.2.1 so that others don't have the same problems as we have had. Many thanks for your help on this
... View more
11-05-2020
08:14 PM
Thanks for the logic analyser trace software link, with this I have been able to see the difference in our traces. We have I2C repeated starts between packets of firmware data that we send whilst your trace does not show this - your firmware appears to be a continuous transmit burst stream. Please could you confim if this is an issue for the BHI260? And if so do you have any suggestions, other than removing the repeated starts as our platform Nordic NRF52840 does not support transmit burst mode as you appear to be using.
... View more
11-04-2020
09:28 AM
1 Like
You have provided your trace in a logicdata binary format which I am unable to read as I do not have access to that analyser. Please can you provide your trace in a text format like the one I provided in my original post. Have you taken a look at my I2C trace to see what I might be doing wrong? The data I am sending in this firmware update is all there, does it look correct to you or not? To simply reply saying yours works is not particularly helpful in helping me to resolve this issue.
... View more
11-04-2020
08:56 AM
Please can you provide the software, or a link to the software, that you used to drive the BHI260 I2C to upload the firmware in your trace so that I can compare it to mine
... View more
11-03-2020
07:25 PM
We have a custom board with the BHI260 interfaced to a Nordic NRF ARM based MCU via I2C however the I2C fails to respond after sending several packets of data. I can read and write the host registers successfully and these are all left at their default states (I2C operation). I have followed the startup and nitialisation procedure from the BHI260 programmers manual and the boot register has it's Host Interface Ready bit set. I now attempt to upload the Bosch_SHUTTLE_BHI260_BMM150.fw firmware to the device by writing the HOST Interface "Upload to program ram" command to host register 0x00 (the command stream DMA register) with the length field set as the number of 32 bit words in the firmware followed by NO STOP. I then attempt to send the firmware 16 bytes at a time with NO STOPs in between until the last packet but only two lots of 16 bytes are received by the device the third is NAK'd for no apparent reason. Here is an I2C trace captured at the BHI260 pins using a logic analyser, where the first line is my command header followed by lines 1-3 which contain groups of 16 bytes I am sending the last of which is NAK'd preventing me from sending more: Start, h50 [ h28 | WR ], h00, h02, h00, h60, h6B, Restart, h50 [ h28 | WR ], h2B, h66, h00, h00, h00, h00, h5A, h17, h3A, h9E, h7E, hFB, h5C, h68, hD5, hC0, Restart, h50 [ h28 | WR ], h7C, h27, hF4, h0A, hF4, hD0, h65, h08, h67, h4D, h72, hF4, hA0, h56, hB4, hF4, Restart, h50 [ h28 | WR ], h07, h64, h7E, h6E, hEF, h83, h00, hDE, h00, h00, h00, h00, h39, h4A, h39, h6B NAK, Stop This all appears to be correct and the data that is sent matches the hex in the firmware file. Just in case this is BHI260 processing issue I reduced the I2C clock speed to 100K and I have tried inserting delays between packet sends but this had no effect. For completeness I have added a scope trace of the I2C data clock, this also appears fine. Are there any known issues uploading firmware via the I2C interface? I notice your BYP2 examples only use SPI and not I2C and there do not appear to be any examples that I can find using I2C.
... View more
Still looking for something?
- Top Results
See all results