Having trouble with code upload... XCode

[saabstutz]

Followed the instructions in Karlis's how-to with XCode and ran into an issue:

Makefile Step1.mk throws an error if board tag is unknown. Error is *** uno board is unknown.
I can see the BOARD_TAG variable XCode is looking for is commented out in the Makefile inside SAAB-CDC on github. When I comment it back in it doesn't like the current board type, mega2560. Error is *** mega2560 board unknown.

I included some small screensnaps below so that you can see the errorDue to the error, XCode keeps telling me build failed. :(

Let me know what I should be defining BOARD_TAG as because I tried to do this with the Arduino IDE and ran into the issue sbt did where a few of the files Arduino doesn't like because it doesn't think they're libraries. I tried building the libraries myself, but after uploading that code I seem to have ruined the functionality for right now. Power LED on but none of the others are. Double :(

Hardware V4.1, btw. Was Software V3.6 trying to be 4.0.

[Karlis]

Hmm, what is the version of embedXcode plugin you are using?

[saabstutz]

I have version 5.4.2. There's not any other config stuff I need to do, right?

[sbt]

saabstutz wrote

I have version 5.4.2. There's not any other config stuff I need to do, right?

saabstutz,

I was able to reproduce your issue with a clean install and download on the code from Github as per the instructions. I was able to fix it by setting the board configuration in the project's release configuration for "SAAB-CDC" to "Arduino Uno". I suspect it's not configured in Karlis's project as pushed to Github, but he may be building the debug configuration instead of the release configuration. Whereas I think Xcode defaults to release builds on first install.



If this was your issue, when you look at this project view now, the release configuration will read "No configurations set". Change it as per image above and retry the build.

Hope this helps.

Cheers,
Sam.

P.S. Karlis may disagree with me on this, but if you're not actively developing BlueSaab, I'd stick with the Arduino IDE to upload the code; you have to install it anyway to use Xcode, but it's a much smaller download. It's easy to fix the library issue you mentioned. Simply manually unzip the files that won't install via the IDE to the "libraries" folder that's within whatever you have the IDE's "Sketchbook location" set to. It should be easy to find, since it will have the libraries from SAAB-CDC release you *can* install. I think this is still far simpler than using Xcode, if you're not experienced with it.

[saabstutz]

I tried that in XCode and unfortunately the issue doesn't seem to have disappeared. I'm working my way through the code and see that it's linking to the file ArduinoUno.xcconfig for the current board tag. Also, if I remove the line that's throwing the board tag error, I get another error: "/lib/version.txt: No such file or directory" It's also giving me a warning about embedXCode not being tested with XCode version 8, so maybe that's the real issue here.

Read up on library building and tried that - it compiled and uploaded through the Arduino IDE but the module doesn't work anymore - I'm getting serial output telling me it's updated and it will interface with the car, but doesn't seem like the RN52 is responding to it. No flashing BT1/BT2 lights. When I update does the RN52 need to be reprogrammed?

I'm using XCode for other projects, so I already had it on my machine - I figured why not use it.

[sbt]

saabstutz wrote

I tried that in XCode and unfortunately the issue doesn't seem to have disappeared. I'm working my way through the code and see that it's linking to the file ArduinoUno.xcconfig for the current board tag. Also, if I remove the line that's throwing the board tag error, I get another error: "/lib/version.txt: No such file or directory" It's also giving me a warning about embedXCode not being tested with XCode version 8, so maybe that's the real issue here.

So you found the release configuration was unset, and you set it?

I'm not surprised removing the lines with errors isn't working, however the warning is odd; I'm not seeing this warning with Xcode 8.2.1, and embedXcode 5.4.2, and in any case, it is working for me and you can probably ignore this warning. Did you revert all the other changes you'd made while trying to get this working? I'd suggest a clean pull from Github.

saabstutz wrote

Read up on library building and tried that - it compiled and uploaded through the Arduino IDE but the module doesn't work anymore - I'm getting serial output telling me it's updated and it will interface with the car, but doesn't seem like the RN52 is responding to it. No flashing BT1/BT2 lights.

OK, it sounds like you have two separate issues here. I did see an issue that sounds like these symptoms (no BT lights blinking) with the released version 4 after I added the Amp shield (to version 5 hardware). I made a PR that's now in the master repo that fixed it for me, as well as ensuring the BT module is programmed correctly. You could try uploading the current master instead of 4.0 release. The Arduino IDE can work with a copy of the repo without worrying about library installations. Just switch to the current master branch in your copy of SAAB-CDC after a git fetch, open the SAAB-CDC.ino file and upload from there.

saabstutz wrote

When I update does the RN52 need to be reprogrammed?

No; uploading new firmware to the ATMega328P will not change the RN52 settings. If your module was working before, it should be OK. If you've done a factory reset though (using the jumper I think that is  on your hardware version) you would need to reapply the settings manually. Sadly, the autoconfigure fix I provided hasn't been backported to hardware versions earlier than 5, although it should work on all v4.x boards since GPIO7 is grounded which avoids serial port speed issues. If the latest firmware doesn't fix your problem, load up the RN52-BT-PRG sketch and post back the results of the "D" command. It will be a list of settings in the module. I'd be surprised if an unconfigured or reset RN52 is your problem; it will normally blink the LEDs even when set to factory defaults.

saabstutz wrote

I'm using XCode for other projects, so I already had it on my machine - I figured why not use it.

Sure; I can see that. It's another variable to eliminate when trying to troubleshoot. I'm sorry I didn't appreciate the significance of this comment in your first post:

saabstutz wrote

I tried building the libraries myself, but after uploading that code I seem to have ruined the functionality for right now. Power LED on but none of the others are.

As above, if you're seeing the same issue I found with SAAB-CDC v4.0 release, try the latest master via git. If that doesn't work, let's see the RN52 check I suggested above.

Cheers,
Sam.

[sbt]

Just to note I've added PR #21 to fix unset board for Xcode release config. Also enabled RN52 auto config for module versions 4.3. Can't enable for v4.1, since not distinguishable from v3.3A, and this doesn't support auto config if 9600_EN jumper not set.

[saabstutz]

Working through the solutions - no luck so far. I've been able to communicate on the serial monitor in the Arduino IDE so I've tried to force it into discoverable, to reset, etc. No luck so far. Thinking I may re-run all of the RN52 initial config tomorrow. Where is the RN52-BT-PRG code?

Also should I take those revisions for PR #21 and put them into my local copy?

[Karlis]

So when you say you are able to communicate through serial, does that mean you are seeing all the "welcome" messages, but RN52 doesn't wake up? If so, you should be able to push RN52 into discoverable mode by pressing "V" while connected to BlueSaab via serial (FTDI/USB).

If that doesn't work, the RN52 programming code can be fetched from here: https://github.com/kveilands/RN52-BT-PRG

Once uploaded and serial connection opened, you should see a "CMD" message appearing. That will let you know that RN52 has "woken up".

Hope this helps.

[sbt]

Edit: Karlis posted above while I was composing this reply. Please follow his advice first.

saabstutz wrote

Working through the solutions - no luck so far. I've been able to communicate on the serial monitor in the Arduino IDE so I've tried to force it into discoverable, to reset, etc. No luck so far. Thinking I may re-run all of the RN52 initial config tomorrow. Where is the RN52-BT-PRG code?

The RN52-BT-PRG code is in Karlis's github profile, at https://github.com/kveilands/RN52-BT-PRG. I have assumed so far that as Karlis made your BlueSaab, it was working with a previous version of the software and the RN52 configuration was already correct. Was it working OK? What prompted you to upgrade the software?

Anyway, there's no harm in checking. Please post the results of the "D" command once you've uploaded the RN52-BT-PRG sketch. I'd be surprised if that wasn't configured already, unless you forced a factory reset at some point.

saabstutz wrote

Also should I take those revisions for PR #21 and put them into my local copy?

If you've already fixed the Xcode project's release configuration for the board (still not clear if you have done), then this patch won't help you. The other change I mentioned doesn't apply to your modules' hardware revision. Sorry for any confusion, the PR was intended to assist others past the issue you've had (and I understood you'd resolved).

For the RN52 configuration, you might find the guide at https://github.com/sambthompson/SAAB-CDC/wiki/Configuration-and-code-upload#rn52-configuration helpful. It's part of a draft wiki I've been working on, but it's still under revision and review.

Please provide as much information as possible about the module's responses, and the steps you try. If you can post logs from the serial monitor, so much the better. After you check the RN52 configuration but before re-uploading the SAAB-CDC sketch, try enabling the debug mode in the RN52 code for more information via the serial monitor. You will need to change the

#define DEBUGMODE 0

to

#define DEBUGMODE 1

in the following files (note: you MUST change them in all these files otherwise bad things will happen; or at least, no good things will happen):

* SAAB-CDC.ino
* RN52driver.cpp
* RN52handler.cpp
* RN52impl.cpp

Don't change them in CDC.cpp or CAN.cpp. Not worried about this for the moment and it will add noise to the log if you enable all the debugging code.

Cheers,
Sam.

[saabstutz]

It was working fine, but I was having a few issues like the steering wheel controls not working when starting the car with the headunit already in CDC mode. Wanted to update to stay with the latest version. I did fix the release configuration.

Tried the RN52-BT-PRG. I am seeing the "CMD" thing, so RN52 is woken up. With "D" command, got the following output:

CMD
*** Settings ***
BTA=000666535201
BTAC=NotConnected
BTName=Sven
Authen=2
COD=200420
DiscoveryMask=06
ConnectionMask=06
PinCode=1234
AudioConfig=0002
AudioRoute=ANALOG
CodecsEnabled=00
AudioCodec=Unknown
ExtFeatures=0084

For some reason it has some extra stuff in that Settings section (see BTAC, AudioConfig, AudioRoute, AudioCodec, CodecsEnabled). It also has it's bluetooth name not as the name I set it to (Sven) but as it's normalized name (BlueSaab-5201). Don't know if it matters, but thought I'd mention it.

When I'm using the RN52-BT-PRG, I can get the RN52 to respond by resetting it/doing the configuration found on your wiki page. I've got the flashing lights! When I unplug it and plug it back in, I'm still getting the flashing lights! Yay!

Here's the weird thing. When I put the CDC software back on the module (as opposed to the RN52-BT-PRG) the RN52 stays in discoverable mode. When I unplug it, and plug it back in, no flashing lights and not discoverable. So seems like the CDC code is getting in the way of the RN52 booting up in discoverable mode? That doesn't seem right since that's one of the configs in the RN52-BT-PRG. When I send the "V" command it refuses to go into discoverable mode. Will report back with more tinkering.

[saabstutz]

Also!

Just found an interesting thing:

"BlueSaab"
Free SRAM: 707 bytes
Software version: v4.0
Hardware version: Legacy
RN52 Error 2 at location: 6
Go back to "Previous" Track
Invalid command.
Invalid command.
RN52 Error 2 at location: 6
Go back to "Previous" Track

That's the output with CDC code. What's Error 2 at location6?

[Karlis]

Thanks for the information!

Ok, so RN52 settings are correct. These are the good news. :)

The bad news - for some reason, software can't detect your hardware revision. It says:

"BlueSaab"
Free SRAM: 707 bytes
Software version: v4.0
Hardware version: Legacy 
RN52 Error 2 at location: 6
Go back to "Previous" Track
Invalid command.
Invalid command.
RN52 Error 2 at location: 6
Go back to "Previous" Track

Where it should say:

"BlueSaab"
Free SRAM: 707 bytes
Software version: v4.0
Hardware version: Hardware version: v3.3A/v4.1/v4.2 
RN52 Error 2 at location: 6
Go back to "Previous" Track
Invalid command.
Invalid command.
RN52 Error 2 at location: 6
Go back to "Previous" Track

And that's where the problem is. Software is instructed to detect hardware revision of the board and if it falls into certain version, pull the PWREN pin on RN52 high thus enabling power to RN52. That's what brings the lights on. RN52 programming code doesn't care about this and pulls that pin high regardless of hardware revision of the board.

So here are two things that can be done and checked:

1. Please check the values on R13 and R11 on top of the board. Those are the HW revision check network resistors.

2. A quick and dirty fix would be to add this line between lines 183 and 184 in RN52impl.cpp file and re-upload the code:

digitalWrite(BT_PWREN_PIN,HIGH);

This should fix it for now. We can work on determining the root cause once we have sorted this out.

Let me know how it goes...

[sbt]

Progress!

Karlis wrote

That's the output with CDC code. What's Error 2 at location6?

Error 2 means "Not Connected", as in there is not an audio channel established between your device and the BlueSaab (because, in this case, the ATMEGA328P can't talk to the RN52 - it's not enabled, as per Karlis's comments).
As you've tried to send the previous track command, this error is reporting location 6, which is the function that passes on your "Previous Track" command to the RN52. This should be fixed by Karlis's suggestion for temporarily bypassing hardware version detection. I was not expecting that to be an issue.

Karlis wrote

1. Please check the values on R13 and R11 on top of the board. Those are the HW revision check network resistors.

Er, isn't it R13 and R14?

You should be able to see the values from the markings, or if you have a multimeter, measure them by probing each end of the component.

R14 should have "1003" on top and measure 100KΩ.

According to the SAAB-CDC code, it's expected that R13 should have "5001" on top and measure 5KΩ.
But, according to v4.1 schematic, it's expected that R13 should have "1002" on top and measure 10KΩ.

Please advise what you have.

Also, if you enable DEBUGMODE as described above, the software will report a "Revision check value" in the messages. Would be curious to see this number.

Cheers,
Sam.

Edit: R13 and 14 not on the bottom; clarify schematic vs. code.

[saabstutz]

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

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.

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

[Seth]

So R13 should actually be a 10k (1002 code) not a 100k (1003 code). That's why the board isn't being recognized properly.

It is a v4.1 board right?

On Wed, Dec 28, 2016 at 17:58 saabstutz [via BlueSaab Forum] <[hidden email]> wrote:

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



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.



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

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-tp879p894.html

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


To unsubscribe from Software, click here.


NAML

[saabstutz]

Ahhhh, that makes sense. It's curious it wasn't a problem with the earlier software. Should I be worried about it since it seems to have no effect on functionality?

[Seth]

I'm not sure why it hasn't been a problem before...and if changing the code works, then fine, BUT you'll have to make sure you add that fix each time you update the software in the future. Which kind of defeats the purpose of the hardware rev check :)

On Wed, Dec 28, 2016 at 19:31 saabstutz [via BlueSaab Forum] <[hidden email]> wrote:

Ahhhh, that makes sense. It's curious it wasn't a problem with the earlier software. Should I be worried about it since it seems to have no effect on functionality?

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-tp879p896.html

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


To unsubscribe from Software, click here.


NAML

[sbt]

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.

Not to worry, you've identified visually. Glad it's working for you. I note that resistors are not polarised, so it doesn't matter which way around you solder them on. R13 on your PCB is marked "REV", so if you do change it, that's the one to replace. R14 is fine.

saabstutz wrote

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

Again, not to worry. You'd need enable the DEBUGMODE to see the rc number on the serial console, but don't need to try this now.

Seth wrote

I'm not sure why it hasn't been a problem before...and if changing the code
works, then fine, BUT you'll have to make sure you add that fix each time
you update the software in the future. Which kind of defeats the purpose of
the hardware rev check :)

Seth,

It looks like the detection code went into v3.7, but Karlis may have shipped with earlier version. I'll admit to still being confused over whether it's correct, since it's configured for 5kΩ resistors in the code, not 10kΩ. It sounds like saabstutz has some dev skills, so he might be able to float Karlis's suggested patch in another git branch, if he's not inclined/equipped to replace R13.

I'm not sure if this would effect any previous hardware revisions, but we could solve this by pulling PWREN high for all revisions. I assume for those where it's already connected to 3V3, there's nothing else on the ATMEGA328P pin? It looks like RN52 PWREN is connected to the ATMEGA328P PB0 pin even on hardware v3.2.

Cheers,
Sam.

[Seth]

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.

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.

On Wed, Dec 28, 2016 at 21:29 sbt [via BlueSaab Forum] <[hidden email]> wrote:

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.

Not to worry, you've identified visually. Glad it's working for you. I note that resistors are not polarised, so it doesn't matter which way around you solder them on. R13 on your PCB is marked "REV", so if you do change it, that's the one to replace. R14 is fine.

saabstutz wrote

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

Again, not to worry. You'd need enable the DEBUGMODE to see the rc number on the serial console, but don't need to try this now.

Seth wrote

I'm not sure why it hasn't been a problem before...and if changing the code


works, then fine, BUT you'll have to make sure you add that fix each time


you update the software in the future. Which kind of defeats the purpose of


the hardware rev check :)

Seth,



It looks like the detection code went into v3.7, but Karlis may have shipped with earlier version. I'll admit to still being confused over whether it's correct, since it's configured for 5kΩ resistors in the code, not 10kΩ. It sounds like saabstutz has some dev skills, so he might be able to float Karlis's suggested patch in another git branch, if he's not inclined/equipped to replace R13.



I'm not sure if this would effect any previous hardware revisions, but we could solve this by pulling PWREN high for all revisions. I assume for those where it's already connected to 3V3, there's nothing else on the ATMEGA328P pin? It looks like RN52 PWREN is connected to the ATMEGA328P PB0 pin even on hardware v3.2.



Cheers,


Sam.

---

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-tp879p898.html

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


To unsubscribe from Software, click here.


NAML