Ok. So stick with Up/Left. All good?

EDIT: If not, this is an indication that we got the resistor values too high.

Yes. Well done there. With the resistors and diode, we definitely now need the digitalWrite(51, HIGH) instead of the weaker INPUT_PULLUP.

Unfortunately, not all good. In order for things to work at all, I have to supply the Betz board voltage from a USB cable connected to its USB connector instead of from the 5v pin from my Pololu power supply.

I'm not understanding why things are different between those two things. The USB tends to supply 4.8v and the Pololu supplies much closer to exactly 5v, but I don't see why those two things are so different as to cause a problem.

I'm happy to try different resistor values. Any ideas?

Looking at the Betz circuit board and the WT32i datasheet, my brain breaks because it goes round in circles. It looks to me like I'm supplying 5v to the VDD_CHG pin which is, I think (not sure) supposed to be the input voltage for the battery charger. Then the VDD_IO is supposed to receive about 2-3v for its main power for serial and bluetooth. I think this happens via a built-in voltage regulator which puts out some unspecified amount of voltage on the pin VDD_BAT which the Betz board does some stuff with.

Betz puts the VDD_BAT output through the SMD-2-pole switch which turns the voltage round and puts it through a little voltage regulator which then is supposed to supply 2.5 volts to VDD_IO.

This voltage only exists because the BT chip itself is putting out the voltage on its VDD_BAT pin and only because that same voltage from VDD_BAT is also looped round and goes back in VREG_ENA which enables the chip's internal voltage regulator so that it can output VDD_BAT so that it can put that voltage back in to VREG_ENA so that it can put out voltage on VDD_BAT so that it .... (sound of head exploding).

In any case, it all sorta kinda works but only if I'm giving it voltage from that USB plug and not from the 5v pin. But what's the difference? there shouldn't be, according to the schematic.

Basically, it's not working right now and I'm not understanding why.

By the way make sure to get the latest code if you're going to try any of this. I've updated the reset line code and stuff. The reset line code seems to work correctly and wakes up the chip when it needs to be waked up. The rest of this stuff is a different story. :-)

Okay, so you get as confused as I do about the incredible amount of work they put into making their schematic as unreadable as possible!

For now, just stick with whatever you have/had working, and I'll try and breadboard it out within a couple of weeks and figure out WTF is going on, and what is needed for us.

Cheers

Thanks so much!

What I had working was the BlueGiga board in Analog audio configuration. That still works, so I can continue to use that.

I was really hoping to get this replacement Betz board working again, to get my digital audio working again. The difference in the sound is subtle, but I'm craving having that digital audio working again.

I've got a few other things I'd like to accomplish on this project, too (final PCB design, final enclosure, etc.), but they all depend on the Betz board with the digital audio working and being tested for a while without frying before I try moving forward with them. So it's good that we're taking our time and being careful about making sure this thing works as designed.

Thanks for all your help and advice!

Update:

If I leave the UART powered, but cut the traces that connect it to the RX/TX lines on the bluetooth chip, then I get clean serial input/output between the Arduino and the Betz board. And digital I2S audio is working great. However this seems to have induced another intractible problem...

Now the Pin 51 reset line isn't working to power up the chip any more. It boots into slow blink mode and I have to push the reset button on the Betz board to wake it up.

I have tried:
- Disconnecting the DTR line that connects the UART to the RESET line by desoldering C4. Does not fix it.
- Trying different timings of setting Pin 51 High, including up to 1 entire second long. Does not fix it.
- Changing the voltage divider on the Pin 51 reset line to let it go up to 3v instead of 2.5v (Did this with a 10k+15k voltage divider though I'm not sure if those are correct for this). Does not fix it.

Blech.

Gag. All of this added complexity because they use 2.5V instead of 3.3V.

The reset pin on the WT32i has to be pulled HIGH during power-on. This should happen with our resistors/diode circuit, but one could give it a helping hand by adding another 10K resistor to pull up the RST signal directly to 2.5V (3.3V).

So that would go betweeen the RST terminal to the 3.3V terminal on the Betz board. Our existing stuff also connects to the RST pin via the diode. No change there.

[EDIT] Of course this might also mean that our existing circuit has to use smaller resistors, to overcome the added 10K pullup. I'll try and breadboard this here today and see what is needed and where.

Okay, I just finished a breadboard trial for the reset lines.

The circuit I used was a pair of 5KOhm resistors for the voltage divider, with one end of the divider tied to GND and the other tied to Arduino Pin-51. The diode connects from between the two resistors directly to the RST pin. Nothing else required, works repeatedly well for me here.

I am still using my original Pin-51 code.. haven't updated the Arduino since I got that working back before Christmas. But the power-on reset logic works even if I disconnect it from Pin-51, as it should/must do.

I am now looking at the lastest BlueGiga code you have in git.

The pin-51 "hardware" reset looks somewhat B0rked to me.

There is no need to first pull the line LOW before then pulling it HIGH to initiate the reset. So nuke that.

Next, I only use the hardware reset here ONCE at power on. Never again. Does it really need to do hardware resets so often in there?

Cheers

What have you done to the sketch? It now just gives a ton of build errors for the latest -git version.

/root/arduino-1.6/sketchbook/BlueGigaEmpeg/BlueGigaEmpeg.ino: In function 'void setup()':
BlueGigaEmpeg:741: error: invalid conversion from 'const __FlashStringHelper*' to '__FlashStringHelper*' [-fpermissive]
Log(F("Built in Arduino Serial has been started."));
^
BlueGigaEmpeg:1860: error: initializing argument 1 of 'void Log(__FlashStringHelper*)' [-fpermissive]
void Log(__FlashStringHelper* logMessage)
^
BlueGigaEmpeg:748: error: invalid conversion from 'const __FlashStringHelper*' to '__FlashStringHelper*' [-fpermissive]
Log(F("BlueGiga Serial has been started."));
^
...

I'll look at the commit history I guess.

Ah.. this fixes it:

Just went out into -23C to try it. Pairing works fine. Didn't get any sound (analog here at the moment), because it went back into a pairing attempt again -- probably due to the dangling wire I have on Pin-52 (pairing "switch").

But pairing worked, so the WT32i is working. That's all I wanted to confirm.

Cheers

Thanks so much for breadboarding it and trying it out!!!

Lots of information in your last few posts, I'll try to consolidate it all here in one post.


The more I look at the datasheets, the more I think that Peter Betz's design which uses 2.5v might be the correct way to do it. 3.3v seems more like the upper limit, with 2.5v being more like the nominal voltage. I think this bears out in my tests, where 3.3v makes the chip run real hot, but 2.5v runs cool.



I think that's the same as me, except that I was using 10k resistors instead of 5k's. This was my configuration:


Would the difference between 5k and 10k make the difference in this case? I'll try it and see if that fixes my issue.

Another idea that occurred to me, what if the problem was that I was doing too much voltage for the RST line instead of too little? What if my attempt to increase it to 3v from 2.5v was the wrong way round? I might try to bring it down a bit and see if that fixes it.



I went through several iterations of it, trying to fix my issue. It's likely that I put some stuff in as an experiment but which doesn't help.



OK, I will remove that. That was one of my experiments to try to solve my issue. My idea was that maybe the sensing logic on the chip's RST line needed a sharper transition than what I was giving it. But it didn't solve the issue, so you're right, I should remove that.



That was another experiment. I was having problems where the chip kept going back to sleep on its own when I would try to do things like pair up the bluetooth module. It would go into its pairing process and then fall asleep again. It was as if the act of a software reboot (the serial "RESET" command in the iWrap language) would put the chip back into sleep mode again. So every time I did a software reboot, also "pressing the ON button" every time seemed to fix it, at least for a while until I had the other problems come up.

If I can get the reset line working at all again, then I will experiment with putting it back to "just once at power on" again, like you originally had it, and see if it works correctly.



It doesn't have any problems compiling for me. There must be differences in the compilers we are using. I will make sure I'm updated to the latest Arduino compiler and make sure it's still working. Check to see if your version of the compiler is updated as well.



Thanks for that!

I'm having trouble following the code changes in your example, but I see that this is an opportunity for me to experience how GitHub works for managing external submissions. Would you be willing to submit that change as a pull request so that I could work with those features? I'm curious how things like permissions work. For instance, can anyone on the internet submit branch changes and then I choose which PR's to pull into Master, or can complete strangers commit directly to my Master? I'm really curious about this since this is my first time hosting a project on GitHub. Also, if you submit a PR, then I'll be able to see your changes in a graphical display and more clearly understand them.

My concern about your changes, the part I want to understand, is where you change "String &logMessage" to "const String &logMessage". My first instinct is that this shouldn't work because there are plenty of strings sent to the Log function set which aren't constants. So it needs to be able to handle all of them. I can't tell from looking at your BBS post how that's handled. So I want to see it in the GitHub comparison screen to understand it.



Thanks so much for literally risking your life for this project!



That's controlled by one of the flags at the top of the code:

It's possible that the one you tried was one of my tests with the I2S audio turned on.

In general, have a quick skim of the true/false flags at the top of the code before uploading the code.

Do you think I should put all those flags into a separate configuration file that gets an #include?

Also, unrelated, I have a separate #include file for the version number of the code but I'm having problems getting a pre-commit hook working which increases that number on every commit into GitHub. Anyone know how to do that? Googling isn't producing enough details for me to actually implement something in that area.



Ah yes, I have noticed that if you leave that pin floating, the Arduino will randomly detect it as being "pressed" and you will occasionally have it restart the pairing process. This is despite the debouncing code I've already got in there. The "button" on Pin 52 should have a pulldown resistor, to prevent the random floating thing from triggering unwanted pairings. From the README.txt:



Interestingly, in your "internal-only" version, I predict you'll be implementing that as a Hijack menu entry instead of a physical button. That will be cool. I'm curious to see what sorts of other UI information and messaging that you'll be implementing.

Right now my code doesn't attempt to detect when Bluetooth is considered "connected" or not. It merely responds to messages on the serial port as needed. I wonder if it should have a flag to try to keep track of that, so that you can display messages on the screen in your "internal-only" version like "Bluetooth connected" or something. Not sure if that would be useful to you or not. In my case I don't care, because my device lives in the trunk, so having an indicator LED for bluetooth connection isn't useful.

Thanks again so much for all your help!

The larger "reference design" (dkwt32i) board we have uses 3.3V, and seems to run fine. The upper limit (datasheet) is 3.6V.


Yeah, I switched to 5K-ohm when actually wiring it up because there's a slight loss across the diode, and 5K-ohm worked so I never tried 10K-ohm.


That's a "unified diff", which is obtained with the "git diff" (or "diff -up") command. All you need to pay attention to are the lines beginning with plus/minus symbols. Delete anything with a minus, and insert anything with a plus. Done. I don't yet know how github works for submissions either, and not sure I'll get to it soon.



The use of "const" in a function parameter simply tells the compiler that the function will NOT be modifying the value of that parameter. So it is safe to pass both const and non-const values to it. Without "const", it really is a programming error to pass in a "const" value.



My style would be to just have a single source file for this. More files is more hassle (eg. the new-ish "version.h"). Header (.h) files are only useful when there are multiple .c files that need the same declarations.

Configuration stuff like that should perhaps be placed as close as possible to the top of the file, to make it easy to find. Or at least that's how most projects I work with seem to have done it.



Don't look at me.. I'm pretty stone age about this stuff!




You can fix that by configuring it as INPUT_PULLUP, and then having the switch pull it to ground (through a resistor) instead of to +5V. Problem solved.


Yeah, I do plan to do that. But I also picked up a nice little panel-mount red button to use during development -- much easier than navigating menus. Couldn't find a similar blue button at the shop (Home Hardware in downtown Toronto).


Now there's an idea.. I might have Hijack overlay a BT symbol onto the display when connected.. hmmmm...


Likewise!

OK cool. But then what do I do with this line?


What are those changes indicating? That's the part I couldn't follow. It looked like you're making changes to that line but I don't understand what it's trying to implement. I thought maybe you were somehow changing that function definition but couldn't tell how.

I could just google that and find it out for myself I suppose! :-)

(Edit: I googled it, and it makes sense. That wasn't a change, it was the marker for which lines in the file the next set of changes applied to. Gotcha.)



Blast, I should know that already. Thank you. Something else I could have simply googled (and I will).

Does this apply even when I'm passing in the variable by reference using the "&" symbol? In that case I was doing it to save memory rather than because I wanted to modify the contents, but in theory it could have modified its contents.

In any case, I'll make the change by adding "const" to those two functions. Thanks!



OK, that's what I'm doing. There's a lot of comments around it, but that's kind of necessary for documenting what the flags actually do.



They should have given that as an alternate example in the Arduino "button" example. Would have simplified my board design. In any case, my current board design already has the layout which includes the pulldown resistor, so I need to leave it in that configuration at the moment.

Are you sure that's a pull-down resistor? Cuz.. if it were, the button line wouldn't be bouncing all over the place.

A pull-down just connects directly between the GPIO pin of the Arduino and GND. There is often a second resistor (which I think you have) in series with the button to limit current draw when the button is pressed. That one isn't really needed here, but doesn't hurt either.

Cheers

Pretty sure it's a pulldown resistor. I was going by this set of instructions which also calls it a pulldown resistor: https://www.arduino.cc/en/Tutorial/Button

But what I meant was, in my design, if I don't have that pulldown resistor connected, then Pin 52 floats and the button line randomly gets input. If I have that pulldown resistor, then it doesn't get random input and everything works as expected.

This can occur if, for example, I don't have the Arduino board docked up to my custom shield/sandwich PCB. The pulldown resistor is on that PCB, so if I've got the Arduino plugged into the USB port of the computer "bare" then sometimes I see the reset/pair routine get triggered randomly.

Since you described your situation as having a "dangling wire" connected to Pin 52, and that you had the reset/pair routine trigger randomly, I was thinking that if you also didn't have pulldown resistor then you were simply running into the same thing.

Actually two 10k ohm resistors with the diode work fine.

I. Found. The. Problem.

Somehow the reset line worked fine when I first got the Betz board, but then at some point, it stopped working. I was measuring voltage on the RST pin on the edge of the board just fine when the Pin51 code triggered, so I imagined that must be fine. I tried doing different resistor networks to try and move the voltage up and down, no effect at all.

Well, one should always check one's assumptions. I was assuming the voltage from our Pin 51 code was reaching the WT32i chip.

NOPE.

Started tracing continuity on the Betz board. The line from the RST pin goes through a Via before connecting finally to one of the legs of the reset button on the Betz board. Somehow, the Via lost its connectivity and stopped transferring voltage through from one side of the board to the other. After tracking the lines to that Via, and scraping away the ink on the top and bottom, I found that there was no continuity through from one side of the board to the other. (And I triple and quadruple checked that it was the correct/same via on either side of the board of course.)

Made a jumper wire go from the RST pin to that leg of the reset button and BOOM the reset line works every time now, with our original design of (in my case) two 10k resistors and a diode.

Bam.

Now: On to that RX/TX serial port garbage issue. Not sure if fixing this will also fix that or not.

Code on GitHub has been updated with the changes you suggested:
- The "const" statement in the log functions.
- A saner pin 51 reset line behavior since the root cause was a board Via problem that couldn't be fixed in software.

The RX/TX serial port garbage is still weird but I am working around it. I'd still like to know the root cause though, before I commit my final PCB design.

Collecting all my thoughts on this problem here in this issue in GitHub:
https://github.com/tfabris/BlueGigaEmpeg/issues/41

Great!

For the TX/RX, it could be an issue with the resistors. Try 5K/5K in place of 10K/10K. This will give stronger drive (more current) to the pin, bringing up the voltage to what we expect.

The issue could be that the internal resistance of the WT32i on those pins is less than (or close to) the 10K resistors, so it skews the resulting voltages. Using smaller resistors (eg. 5K/5K) could swing the balance back in our favour.

I have not breadboarded this yet, but do give it a go.
Do NOT go any lower than, say, 1K/1K though -- that should be more than low enough.

OK cool, I'll try that, thanks!

A couple of questions about it....

Which resistors specifically?

Voltage dividers exist on the I2S pins. The I2S pins are working perfectly and I would be concerned about changing them. Not just because of "if it ain't broke don't fix it" but also because the whole reason they exist is to protect the WT32i chip from being fried. Though, if you say that those I2S lines might possibly be related to the serial port issue, I'm willing to try.

There is the voltage divider on the reset line. It is inactive (in "read" mode) when I am reproducing the issue. If it's not doing anything when the bug is happening, my guess is that it can't be related. Though I'm not sure because EE surprises me frequently and you know much more about that than I do.

The only remaining voltage divider is on the Arduino's TX2 line that runs into the WT32i's serial RX pin. That's not where I'm seeing the issue recur, rather, I'm seeing it on the WT32i's TX line (the one coming into the Arduino RX2).

I actually don't know if the WT32i's RX line is encountering the corruption or not, because it's necessary to have local echo turned off on the WT32i for smooth software operation. Though I suppose I could certainly turn it on briefly to test it and look for a problem. Though interestingly, even if I did that, I wouldn't be able to tell. I would be getting the data back through loopback echo from the WT32i, coming back on the same channel that's encountering the bug. So I wouldn't be able to tell if the issue was in the transmit or the receive in that case.

I do not have any resistors at all on the WT32i's serial TX line that runs into the Arduino's serial RX2 pin. And yet that is the place where I see the text being occasionally corrupted: Messages from the Bluetooth are sometimes turning into garbage characters on their way into the Arduino. (This is not a buffer overflow by the way; buffer overflows drop characters, and this is not drops, this is corruption.)

Do you think that possibly it might be caused by not enough voltage on that TX line coming in from the WT32i?

I think I have a bag of 1k resistors around here, and I definitely have a big bag of 10k's but probably not any 5k's (though I'll look again). If I wanted to test this in a hurry with what I have on hand, which do you think would be better, swapping out the 10k's for 1k's, or, doubling up the 10k's in parallel to make 5k each?

Oh, that direction. Wow.. never figured there would be an issue on that one. But 2.5V is close to borderline for the Arduino's serial RX line. Yet another issue from using 2.5V rather than 3.3V perhaps. Or we could even point fingers at Arduino for using 5V boards when practically all other devices want 3.3V.

This is fixable with a transistor, but maybe a simple resistor would help too. I don't see what the output drive current limit is for the serial TX from the WT32i datasheet, but let's assume it can push perhaps 3mA at 2.5V (guesstimate based on a typical 5mA capability for 3.3/5.0V logic).

A 1K-ohm pull-up on that line would suck an extra 2.5mA of current, so that's a bit close for comfort. But a 2K-ohm pull-up (two 1K in parallel) would draw only half that, and might help to pull the output voltage up high enough for more reliable serial.

So give that a try: 2K-ohm pull-up resistor between the Arduino's RX line and +5V. If no worky, then we'll look at some active level conversion circuitry (aka. a transistor or similar). Or a prefab device like this or this.

Cheers
-ml

Lack of sleep again , Mark...?

Two 1k in parallel would give 0.5k, not 2k. Two 1k in series would give 2k resistance.

Br,
Stig

Yes I’m sure he meant series.

So then like this?



Does this pose any sort of risk to the WT32i chip? I only just got my replacement chip working so I am afraid I'll fry it again if I get this wrong. On the other hand, I want a reliable system that I can make in kit form for other Empeg users, so I'm interested in making sure this works right, and until I solve this serial port problem it's not really kit-able.

The amount of garbage I'm seeing on those serial ports is very small and intermittent, so I think I would only need a very small amount of pullup current. Should I first try a 5k pullup for an even smaller amount of pullup current?

No significant risk to the WT32i from that. Like I said, at most it will draw a bit more than an extra milli-ampere from the WT32i TX pin when the pin is driven LOW.

Should be safe enough.

Tell me about it! Thanks for saving the day here!

Cheers

Thanks Mark!

And my "Before" and "After" schematic is correct?