Having trouble with code upload... XCode

[sbt]

Sorry, I meant PB1.

Seth wrote

Yes it's possible that module shipped before the hw rev code went into
effect. We (Karlis & I) arbitrarily picked some resistor values to go with
the certain hw versions, so I might've been wrong with the value it
"should" be. The best way would be to make the REV resistor the proper
value.

Fair enough. Which is the proper value for this revision? Did any boards ship with 5kΩ REV resistors? All the schematics I have seen back to 3.2 have 10kΩ for REV. As it stands, the code will detect all versions (with the correct resistors fitted) from 3.2 to 4.3 as v4.3. (I assume 4.3 also had 10kΩ; the schematic for this wasn't published).

Seth wrote

The only issue with pulling PWREN high all the time is because (I think;
it's been a while) the old modules (3.2?) have PWREN pin on arduino going
to AIC0 on RN52, and if that pin is high the RN52 can't boot, so we started
using the hw rev resistors to identify which modules need which pins pulled
high/low.

It doesn't look like this applies to 3.2, must be earlier. There's an analogue GPIO (pin 4) AIO0 on the RN52, but it's claimed to be bidirectional programmable I/O; I'd be surprised if it stopped RN52 from starting when high. Do you recall why this was hooked up to PB1 on the ATMEGA328P? I can't find any application notes or examples for using this pin on the RN52. PB1 is a PWM capable pin, so it looks like intention was a non-digital/binary signal.

Still, if it is a problem, I guess saabstutz will have to fix hardware or float the patch.

Cheers,
Sam.

[Karlis]

saabstutz wrote

Well that was easy. Added Karlis's quick fix, and powered up right away.

Yay!

saabstutz wrote

For me R13, is a 1003 rotated 180 degrees (as compared to R14 and the writing on the board) R14 is a correctly rotated 1003. They say 100K next to them on the board, but I don't have a multimeter so unfortunately I cannot get a real world reading on that.

R11 is a 223, marked as 22K, if that matters.

Can you please take a (good as possible) picture of that part of the module and post it here? I'm biting my fingernails off at the moment thinking I've screwed up the soldering job... :)

saabstutz wrote

What command gives me the revision check number? I remember seeing it earlier but can't find it again...

There's no specific command for getting hardware revision version. It just show's up in the "welcome" part of the code as it is being executed in the setup() part of the code.

[Karlis]

And yes... I just checked, BlueSaab module was shipped to saabstutz in mid August this year. Waaaay before hardware revision checks in the code, PWREN pull-ups and so on. I am sorry. My bad. Let's work on fixing this. I would still need to see that picture I asked in previous comment to double-check that HW part is ok.

[Karlis]

sbt wrote

Sorry, I meant PB1.

Seth wrote

Yes it's possible that module shipped before the hw rev code went into
effect. We (Karlis & I) arbitrarily picked some resistor values to go with
the certain hw versions, so I might've been wrong with the value it
"should" be. The best way would be to make the REV resistor the proper
value.

sbt wrote

Fair enough. Which is the proper value for this revision? Did any boards ship with 5kΩ REV resistors? All the schematics I have seen back to 3.2 have 10kΩ for REV. As it stands, the code will detect all versions (with the correct resistors fitted) from 3.2 to 4.3 as v4.3. (I assume 4.3 also had 10kΩ; the schematic for this wasn't published).

PCBs v3.3A, v4.1 or v4.2: 100K/5K Ohm
PCB v4.3 100K/10K Ohm
PCB v5.0 100K/20K Ohm
PCB v5.1 100K/25K Ohm (not sure yet)

Seth wrote

The only issue with pulling PWREN high all the time is because (I think;
it's been a while) the old modules (3.2?) have PWREN pin on arduino going
to AIC0 on RN52, and if that pin is high the RN52 can't boot, so we started
using the hw rev resistors to identify which modules need which pins pulled
high/low.

It doesn't look like this applies to 3.2, must be earlier. There's an analogue GPIO (pin 4) AIO0 on the RN52, but it's claimed to be bidirectional programmable I/O; I'd be surprised if it stopped RN52 from starting when high. Do you recall why this was hooked up to PB1 on the ATMEGA328P? I can't find any application notes or examples for using this pin on the RN52. PB1 is a PWM capable pin, so it looks like intention was a non-digital/binary signal.

Still, if it is a problem, I guess saabstutz will have to fix hardware or float the patch.

Cheers,
Sam.

[sbt]

Karlis,

Karlis wrote

PCBs v3.3A, v4.1 or v4.2: 100K/5K Ohm
PCB v4.3 100K/10K Ohm
PCB v5.0 100K/20K Ohm
PCB v5.1 100K/25K Ohm (not sure yet)

This list matches the code. But in looking at the schematics for v3.2 through v4.2, the value specified for R13 is 10kΩ (and you also said originally that's what saabstutz's BlueSaab v4.1 should have). Were any built with 5kΩ?

Aside from having the GPIO7 pin locked low to force 9600 to the RN52, is there any other issue with not being able to distinguish these versions? From what I can see, if they can't be told apart, then RN52 auto configuration can't be enabled for any of them, since v3.3A doesn't have the baud lock. That would be a shame for the current users as new RN52 features like track change and power saving are enabled; they would have to manually configure the RN52 to add these settings.

Cheers,
Sam.

[Karlis]

HW revision check was something me and Seth came up with really late in this project. Software-wise post v3.3A. Though Seth, being the true visionary of hardware for this whole thing, had already provisioned for it beforehand. Then we came up with the resistor values for divider network to distinguish between different versions. I don't recall the exact reasoning behind the values we picked, but I *think* we went with a pair of 100KOhm/bottom->top "X" KOhm value pair, just to "streamline" things.

Apart from GPIO7 being pulled low (9600 baudrate by default) we are working on implementing more energy-efficient features. For instance, starting v4.3 SN CAN transceiver chip can be put to sleep and woken up per need basis (= saves power). Same with upcoming v5.1 - we could force a total shutdown of power for x amount of seconds to the module thus reseting it completely (if we ever need).

All of this would also help us with implementing RN52's sleep/wakeup feature (= saves power), but we are quite a few steps away from it yet. :)

[Seth]

Yes, pretty much what Karlis just said.

The schematics don't match the hw REV resistor values because at the time they weren't being used. I should go back to all of them and edit the schematics to match the resistor=rev chart Karlis posted.

When we did have the 328 tied to the AIC0 pin on rn52, we thought we might have needed it. Turns out we didn't need AIC0, so we remapped that pin to be the PWREN pin on every board since 3.3A (or something). But I do know for a fact that if the AIC0 pin is high when the rn52 is powered on, it will not boot.

At one point I wasn't thinking correctly and thought that we needed a pwm pin to give the PWREN pin 3.3v instead of 5v (through a rc network). But I'm retarded because the 328 was already running on 3.3v so the output of any pin would be 3.3 already, not 5v.

The AIC0 pin remap is a large part of the reason we started implementing the hw rev checks, as well as other hardware changes that the firmware cares about; like switching from 328P to 328P-AU (there are 2 extra analog I/O's on smt 328).

On Thu, Dec 29, 2016 at 03:22 Karlis [via BlueSaab Forum] <[hidden email]> wrote:

HW revision check was something me and Seth came up with really late in this project. Software-wise post v3.3A. Though Seth, being the true visionary of hardware for this whole thing had already provisioned for it beforehand hardware-wise. Then we came up with the resistor values for divider network to distinguish between different versions. I don't recall the exact reasoning behind the values we picked, but I *think* we went with a pair of 100KOhm/bottom->top KOhm value pair, just to "streamline" things.



Apart from GPIO7 being pulled low (9600 baudrate by default) we are working on implementing more energy-efficient features. For instance, starting v4.3 SN CAN transceiver chip can be put to sleep and woken up per need basis (= saves power). Same with upcoming v5.1 - we could force a total shutdown of power for x amount of seconds to the module thus reseting it completely (if we ever need).



All of this would also help us with implementing RN52's sleep/wakeup feature (= saves power), but we are quite a few steps away from it yet. :)

If you reply to this email, your message will be added to the discussion below:

http://bluesaab-forum.2349123.n4.nabble.com/Having-trouble-with-code-upload-XCode-tp879p905.html

To start a new topic under Software, email [hidden email]


To unsubscribe from Software, click here.


NAML

[sbt]

Seth wrote

The schematics don't match the hw REV resistor values because at the time
they weren't being used. I should go back to all of them and edit the
schematics to match the resistor=rev chart Karlis posted.

OK, from this I take it that saabstutz's v4.1 module should have a 5kΩ resistor for R13/REV, should he decide to replace it, not 10kΩ as posted previously...

Seth wrote

When we did have the 328 tied to the AIC0 pin on rn52, we thought we might
have needed it. Turns out we didn't need AIC0, so we remapped that pin to
be the PWREN pin on every board since 3.3A (or something). But I do know
for a fact that if the AIC0 pin is high when the rn52 is powered on, it
will not boot.

... and from this I conclude that PWREN cannot just be enabled for all boards. So it's either a hardware fix or ongoing software patch for saabstutz's module (and any others with the same resistors).

Thanks for confirming.

Cheers,
Sam.

[saabstutz]

Thanks you guys for the help. I'm amazed every day that a dead car brand can have such dedicated following, from the repairing/modding forums to here. You guys have been a huge help.

Also, cool to see you got the SID text to work. When I hopped into the car after installing it today, I got a huge smile on my face seeing that. Open software works!

Instead of saying Legacy on that hardware check, could we say hardware version not detectable? I had seen that earlier, but assumed it was fine - I had no clear indication that that was out of whack, when it really needed to be v3.3A/v4.1/v4.2.

I will send that picture later tonight when I get a chance. I'll probably end up fixing that resistor, but it's gonna have to wait a bit. Such is life.

Now to figure out why XCode still doesn't like me...

[sbt]

Great to hear your BlueSaab is back in action!

saabstutz wrote

Now to figure out why XCode still doesn't like me...

You mentioned that you'd fixed the release configuration. If something's still broken, can you confirm your version of Xcode, as well as what the symptoms are that you have now, and how to trigger them?

Did you follow the embedXcode template install instructions (from the embedXcode user manual) to the letter?

Cheers,
Sam.

[saabstutz]

Here's the pic.