Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

writing program to bq8030 doesn't work #10

Open
jalr opened this Issue Sep 8, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@jalr
Copy link
Contributor

jalr commented Sep 8, 2018

  1. I'm having trouble flashing the program. Normally I would blame my hardware for this but I played around with two batteries and both showed the same issue. One is now bricked but the other works so I can still try things out ;)

  2. In your blog you mentioned that Error -11 means LIBUSB_ERROR_NO_MEM.
    I tried to understand why that would happen and came across the writeProgramBlock function where you return status-2. If I understood that correctly SMBWriteBlock returns the size written successfully or alternatively a negative number in case of an error. If that is correct you should return (status > 0 ? status-2 : status); in writeProgramBlock and the same for writeEepromBlock. I'll send you a PR if you confirm this.

smbusb_bq8030flasher -f prg.bin --confirm-delete
------------------------------------
        smbusb_bq8030flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
PEC is ENABLED
TI Boot ROM version 3.2
------------------------------------
Erasing program flash
Done
Flashing program flash
Error:-11

writing the eeprom works like a charm:

smbusb_bq8030flasher -w eep.bin --confirm-delete
------------------------------------
        smbusb_bq8030flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
PEC is ENABLED
TI Boot ROM version 3.2
------------------------------------
Erasing eeprom(data) flash
Done
Flashing eeprom(data) flash
................................................................
Done!
Verifying
................................................................
Verified OK!
@karosium

This comment has been minimized.

Copy link
Owner

karosium commented Sep 8, 2018

Hi,

Ah, that explains it! Confirmed, feel free to send the PR.

So it was actually LIBUSB_ERROR_PIPE (-9) then... more realistic but still doesn't tell me much.
However I am wondering whether increasing the usleep delay in writeProgramBlock() would have any effect. It was a totally arbitrary number I settled on because it seemed to work for me. I've successfully reflashed a bq8030 program flash a total number of 2 times which was the extent of the testing I did on this but 2000uS might be cutting it too close for writing the program flash blocks (and usleep might not be that consistent across systems either).

Could you try it with usleep 5000, 10000, 100000 in writeProgramBlock()?

Thanks

@jalr

This comment has been minimized.

Copy link
Contributor Author

jalr commented Sep 8, 2018

OK I debugged a little further and found out that first 64 bytes are transferred in the SMBWriteBlock function. Then after attempting to transfer the remainder the error -9 is returned.
So in my case the usleep() never gets called.
Documentation says LIBUSB_ERROR_PIPE is returned if the control request was not supported by the device.

@jalr

This comment has been minimized.

Copy link
Contributor Author

jalr commented Sep 8, 2018

I just wanted to check if the first 64 bytes are written to the flash but no. Instead if I dump the program memory I see the repeating pattern ff ff 3f. The pattern repeats until the address 0x11040. From there on it is filled up with ff.

@karosium

This comment has been minimized.

Copy link
Owner

karosium commented Sep 8, 2018

ff ff 3f is NOP in CoolRISC. It's what the program flash blocks are erased to so basically it's blank.

If the first call goes through and you get the error on the second then the delay could still be at fault. If the chip is still writing the first block when the command to write the second comes in it could mess things up and possibly even block the write that's in progress so I would still try with increased delays.

If it's not that then unfortunately I have no clue.

@jalr

This comment has been minimized.

Copy link
Contributor Author

jalr commented Sep 8, 2018

Yes! Thanks, that was the right hint. I fixed it with a usleep(10000000) after eraseProgramFlash(). Do you have any ideas how we could do this properly instead of relying on the correct timing?

@karosium

This comment has been minimized.

Copy link
Owner

karosium commented Sep 9, 2018

Nice, glad you could get it to work!

Yeah, the delays were always a hack. The right way would be to read the correct status register through the TI BootRom interface that says whether the flash is busy or not and keep reading it until it isn't. Someone would need to find the correct command(s) in one of the many TI PDFs and implement it.

So it's either that or bumping up sleep(1) in eraseProgramFlash(). I'm guessing 10 seconds is probably overkill so if you could test it at second intervals and then double the lowest that works for you that'd probably be fine.

I'm fine with merging a pull request with either approach ;-)

@0r10nV

This comment has been minimized.

Copy link

0r10nV commented Sep 25, 2018

we can implement variable time delay in respect to data block length to be written, I've seen this approach in TI sample code in slua801.pdf ("Gauge communication and flashstream examples", p.14, 'gauge.c')

n = atoi(pBuf);
usleep(n * 1000);

p.s.
as was observed usleep() is not really doing what it should do, especially with small delays, I have not managed to make it precision micro delays om my system (Win7 32bit), for a range of arguments from 1 to 16000 it gives constant delay of 16ms, but usleep(100000) gives unexplainable 0ms, so no delay at all!

@karosium

This comment has been minimized.

Copy link
Owner

karosium commented Oct 9, 2018

Good find 0r10nV, best-practices from TI would be great to adopt. Unfortunately I can't really work on this anytime soon besides quickly skimming and merging PRs so someone would need to add and test the improvements and submit one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.