Flashing not working
#11
(05-06-2020, 07:31 AM)danielt Wrote:
(02-28-2020, 10:15 PM)cjmakes Wrote:
(02-24-2020, 06:36 AM)wibble Wrote: Are you sure it's the same error? You say you're using the bcm2835spi driver, but the debug output above is for the bitbanging bcm2835gpio driver.

Yes, different driver, same error.

Had you *previously* been using the bcm2835spi driver?

AFAICT bcm2835spi contains a sneaky trick where both the RPi and the nRF52 will be outputting data on the SWDIO pin at the same time (e.g. the RPi pushes 0v whilst the nRF52 pushes 3v3 for some cycles). Without some kind of current limiting resistor inline on the SWDIO line then this sounds a bit risky to me

I added a 330Ω inline resistor which should result in safe 10mA max current in this case but the error still appeared. Also if it was a real short I'd expect the device be a little more broken or at least behave like being disconnected (if you assume that the port is damaged) but it behaves differently.
  Reply
#12
(05-25-2020, 08:46 AM)jkl Wrote:
(05-06-2020, 07:31 AM)danielt Wrote:
(02-28-2020, 10:15 PM)cjmakes Wrote:
(02-24-2020, 06:36 AM)wibble Wrote: Are you sure it's the same error? You say you're using the bcm2835spi driver, but the debug output above is for the bitbanging bcm2835gpio driver.

Yes, different driver, same error.

Had you *previously* been using the bcm2835spi driver?

AFAICT bcm2835spi contains a sneaky trick where both the RPi and the nRF52 will be outputting data on the SWDIO pin at the same time (e.g. the RPi pushes 0v whilst the nRF52 pushes 3v3 for some cycles). Without some kind of current limiting resistor inline on the SWDIO line then this sounds a bit risky to me

I added a 330Ω inline resistor which should result in safe 10mA max current in this case but the error still appeared. Also if it was a real short I'd expect the device be a little more broken or at least behave like being disconnected (if you assume that the port is damaged) but it behaves differently.

I've been trying to avoid saying too much here, mostly because the only verbose log in the thread is a bcm2835gpio driver failing to read an ID from the target (which is consistent with damage to a pad driver for a pin but also is consistent with may other failure modes too). That's not a lot to go on and thus any long comments from me would just be filled with speculation which would probably just feed into the disinformation grinder. So I am concerned by the number of people reporting "it worked for a bit then broke (permanently?)" but its not even clear what exactly is the common behaviour among those users.

I'd suggest everyone who is having problems describe the exact behaviour they see. If possible, avoid "same as @another_person" descriptions since reports like that give no clue of the level of care that did (or didn't) go into the additional report. Perhaps the following prompts are useful:

How *exactly* does your device behave now (perhaps use a pastebin or github gist to store the verbose logs from openocd)? How it is hooked up (and have you changed the way it is hooked up)? What driver are you using (bcm2835spi, bcm2835gpio, ...)? Was it working previously? If it was working previously please also describe how it was hooked up at the point it stopped working and which driver you were using at that point?
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
  Reply
#13
I just ran into this issue now. I'm using the "spi" driver I think. (full log here: https://gist.github.com/slembcke/d90fc516d1225edb58f7177741d30e47)

Since this thread is somewhat dead, I assume that nobody has figured it out? Did anybody ever try flashing the same board with a dedicated interface after running into this issue?
  Reply
#14
The key line in the logs is this one

> JUNK DP read reg 0 = ffffffff

I believe this means that when the RPi tried to read the device ID from the watch is gets all 1s. In other words the watch either did not receive the request or it was not able to reply.

This can happen when something has been damaged... but, assuming the line has a pull up, then I think you'd be likely to see exactly the same result if one of the wires fell out ;-) (which you can easily test of course).

Unfortunately even when we know there is damage it is very hard to distinguish how the damage occurs (the SWD pads on the board are pretty fragile... I broke one of my devices but it was definitely physical damage rather than anything electrical).

For certain, it is really good idea to try flashing with a dedicated interface if you can borrow one!
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Accelerometer stopped working victor9 14 3,757 11-22-2022, 04:12 PM
Last Post: wibble
  PineTime Touch Screen Stopped Working BlunderingBushcraft 3 1,224 07-30-2022, 04:19 PM
Last Post: headgr
  can anyone suggest their working Linux bluetooth USB dongles to connect to Pinetime? jahway603 4 855 07-27-2022, 07:38 PM
Last Post: jahway603
  Flashing with RF Connect ronaldheld 12 2,756 04-28-2022, 04:27 AM
Last Post: ITCactus
Question [question] how to restore PineTime to a factory state after flashing non-OTA/directly ITCactus 2 1,084 04-11-2022, 05:03 AM
Last Post: ITCactus
Question Which companion apps work best for flashing firmware and pairing/syncing w/ Pinetime? danimations 0 765 03-28-2022, 08:22 PM
Last Post: danimations
Sad Account not working - missing permissions? Droidian 0 818 09-24-2021, 05:30 AM
Last Post: Droidian
  Working with Fito Track Glockdoc 2 943 09-04-2021, 10:23 AM
Last Post: barray

Forum Jump:


Users browsing this thread: 1 Guest(s)