AOUT NG J1 Connection Confusion

[greevous]

Can someone tell me the proper way for J1 to be connected to the STM32 core?

I've got it connected to J19 (RC1 side), and I think I've got all the pins figured out except #5.

J1.1 = GND (Vs on core J19)

J1.2 = +5v (Vd on core J19)

J1.3 = Frame Sync (SO on core J19?)

J1.4 = Digital Serial Input (RC1 on core J19?)

J1.5 = Serial Clock Input (SC on core J19?)

I'm beginning to think my assignment for J1.3 is wrong... maybe J1.4 should be SO on core J19, and J1.3 should be RC1? Then what is J1.5, SC on the core? Since "SO, SC, and RC1" don't really match to the pins of the DAC or the pins of the STM32 itself, it's a little confusing.

Right now I'm getting nothing but a slightly glitchy fixed voltage out of all 8 channels of the AOUT NG, but I think it's because I'm not driving the DAC properly due to confusion on the J1 interface. The only pins I know for sure are right are GND and +5v.

[TK.]

Hi,

you swapped J1.3 with J1.4, here the correct connections (see also http://www.ucapps.de/midibox_seq/mbseq_v4_interconnections.pdf - the pin order on the 25 pin female socket matches with J1 of the AOUT and AOUT_NG module)

J1.1 = GND (Vs on core J19)

J1.2 = +5v (Vd on core J19)

J1.3 = Frame Sync (RC1 on core J19!)

J1.4 = Digital Serial Input (SO on core J19!)

J1.5 = Serial Clock Input (SC on core J19)

Right now I'm getting nothing but a slightly glitchy fixed voltage out of all 8 channels of the AOUT NG, but I think it's because I'm not driving the DAC properly due to confusion on the J1 interface. The only pins I know for sure are right are GND and +5v.

Hint: there is a nice AOUT debugging function which is integrated into the MBSEQ V4 application, and which allows you to check the AOUT board interconnections.

Type "testaoutpin" in the MIOS Terminal to get following help page:

[111127.163] testaoutpin

[111127.166] Please specifiy valid AOUT pin name: cs, si or sc

[111127.166] Following commands are supported:

[111127.166] testaoutpin cs 0  -> sets AOUT:CS to 0.4V

[111127.167] testaoutpin cs 1  -> sets AOUT:CS to ca. 4V

[111127.167] testaoutpin si 0  -> sets AOUT:SI to ca. 0.4V

[111127.167] testaoutpin si 1  -> sets AOUT:SI to ca. 4V

[111127.167] testaoutpin sc 0  -> sets AOUT:SC to ca. 0.4V

[111127.167] testaoutpin sc 1  -> sets AOUT:SC to ca. 4V

[111127.167] testaoutpin reset -> re-initializes AOUT module so that it can be used again.

[/code]


Use this utility to doublecheck the pin assignments.


Best Regards, Thorsten.

[greevous]

Well, I got those wires switched as they should be, but I'm not getting anything out of any of the output channels on the AOUT NG. I checked the Op Amps, and they're definitely getting their V+ and V- as they should.

Can I load the MBSEQ .hex even if my setup doesn't include all the hardware for the MBSEQ? Basically I've got a single chip DIN module, and AOUT NG module, and a single CLCD module.

I hooked a scope up to J2, and I definitely have Vd, Vs, and a pin that seems to strobe low when I rotate my encoder. Is that the clock line? I'm sort of a newbie to this and I don't really know how to debug from here. When I built my AOUT LC, it just worked, so I didn't need to debug anything. This time I didn't get so lucky I guess.

[greevous]

I installed the MBSEQ program, and used the testaoutpin functions, which definitely showed a +4 / 0 thing happening on each pin when I told it to (although I noticed that they varied a little -- one pin was around 5v and another was around 4 when turned on), but I'm not getting anything out of the output channels. Any ideas how I should debug?

[TK.]

Which pin was 5v?

Sounds like a connection error!

Could you please take a photo of the wiring and attach it to this thread? This could help me to understand the problem.

Best Regards, Thorsten.

[greevous]

Here's a couple of photos.

I hooked up my oscilloscope to each pin and watched its behavior. When I use the testaoutpin thing in MBSEQ, I can toggle each pin up or down as you would expect. However, when I use the AOUT Tutorial #16 with my midi keyboard, the SC pin never moves off of GND. When I use my little test program (which just sends a 16 bit counter value to channels 1, 2, and 3), I see the same thing -- the SC pin doesn't move off of GND. The other two serial pins seem to be doing something.

one of them looks sort of like (where the _ is actually very tiny)

------_--_-------_--_-------_--_

and the other one looks sort of like

--------___---------_________--__

but the SC pin looks like

_________________________________

I looked at the datasheet for the DAC, and I guess I would expect the SC pin to look like this, correct?

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

Any help would be appreciated. Should I try switching to the second set of pins in the J19 block? I don't understand why I can set SC just fine with the MBSEQ tool, but when I use anything that actually sets the value through the normal API, SC doesn't seem to do anything.

[greevous]

I've created a PNG that shows my oscilloscope on all three serial pins (the vd and vs are normal). First I show myself manipulating them with the MBSEQ tool (demonstrating that they work). Then, I show all three while I'm sending data to the AOUT. You'll notice the SC doesn't seem to do anything while I'm rotating the encoder.

I've attached my test code as well, in case this is some kind of software problem (although I don't think it is, because I don't get anything out of any of the output channels of the AOUT NG with Tutorial #16 when sending data from my synth via midi -- I see the MIDI messages in the console, but nothing from the AOUT NG outputs).

app.c

[greevous]

I forgot to mention that this whole exercise is to get a high quality MIOS32/DAC combo that is going to be used to drive the keyboard and left-hand-controller circuits for my Minimoog clone:

http://sites.google.com/site/minimoogwiki/

I already had it "sort of" working with a MIOS8 and an AOUT LC, but that was too limited because I couldn't fit all the code in it and needed more output channels to drive the left-hand-controller circuit (I'm replacing the original left hand controller and the keyboard with a MIOS solution so I can use my minimoog clone with the rest of my synth rig [Roland Junu-G, Roland JV-30, Roland JX8P, Korg Microkorg]).

[TK.]

Should I try switching to the second set of pins in the J19 block?

This won't help, because these are different pins (except for SC, Vs, Vd)

It seems that your AOUT_NG module is already connected to the right pins (but it's a bit confusing that the colours are a different on the pictures)

I don't understand why I can set SC just fine with the MBSEQ tool, but when I use anything that actually sets the value through the normal API, SC doesn't seem to do anything.

The SC pulses are very short, sometimes ca. 100 nS (= 5 MHz)

Did you select the right timescale on your scope?

It would be interesting if you can see the pulses if the cable on the SC line is disconnected from the MBHP_CORE_STM32 module.

Maybe the cable is too long? (what is the cable length?)

Note that J19 is a software emulated SPI port. This means, that if MBSEQ can control the pins, MIOS32_SPI should be able to do this as well without reconfiguring the IO pin.

Are you using the prebuilt binary (beta44), or did you build the application by yourself?

Did you already ensure that you are using the latest sources of the repository, and that you are not using modified sources?

Best Regards, Thorsten.

[greevous]

...but it's a bit confusing that the colours are a different on the pictures...

Only the red wire is different (changes to brown because I had to splice it)... I should have mentioned that when I uploaded the pictures. I forgot about it.

The SC pulses are very short, sometimes ca. 100 nS (= 5 MHz) Did you select the right timescale on your scope?

I'm not sure. I'll double check the timescale.

It would be interesting if you can see the pulses if the cable on the SC line is disconnected from the MBHP_CORE_STM32 module. Maybe the cable is too long? (what is the cable length?)

The cable is about 20 cm long. I've measured both from the J19 interface on the core, and the J1 interface on the AOUT NG... both show nothing for SC unless I use the MBSEQ tool to force SC high or low.

Note that J19 is a software emulated SPI port. This means, that if MBSEQ can control the pins, MIOS32_SPI should be able to do this as well without reconfiguring the IO pin.

Are you using the prebuilt binary (beta44), or did you build the application by yourself?

Did you already ensure that you are using the latest sources of the repository, and that you are not using modified sources?

I built the apps using the source trunk, which I checked out about two weeks ago and refreshed last night to get the MBSEQ stuff. Maybe my toolchain is screwed up in some way? This seems doubtful though -- everything compiles fine.

Maybe I need to dig into the source code of MBSEQ v4. Obviously MBSEQ's testaoutpin code is able to drive all three pins on and off by command, so there must be some difference between what it does when it's driving them manually vs. when I use AOUT_PinSet(). I wish I had a multichannel oscilloscope... I'd like to watch all three at the same time...

If I can't get J19 working, is it possible to use J8? I'm currently using J9 for a DIN interface, but my understanding is that J8 is a hardware SPI interface?

[TK.]

I built the apps using the source trunk, which I checked out about two weeks ago and refreshed last night to get the MBSEQ stuff. Maybe my toolchain is screwed up in some way? This seems doubtful though -- everything compiles fine.

Please try the prebuilt binary, just to ensure...

Note that the source code should be compiled with the official MIOS32 toolchain package, otherwise you could notice random effects, such as "overoptimized" or "worse optimized" code. It could even happen that certain functions won't work anymore due to a new (or old) gcc bug.

Maybe I need to dig into the source code of MBSEQ v4. Obviously MBSEQ's testaoutpin code is able to drive all three pins on and off by command, so there must be some difference between what it does when it's driving them manually vs. when I use AOUT_PinSet(). I wish I had a multichannel oscilloscope... I'd like to watch all three at the same time...

The AOUT driver uses the MIOS32_SPI_TransferByte() function in MIOS32_SPI_MODE_CLK0_PHASE0 mode to drive the pins:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2FSTM32F10x%2Fmios32_spi.c

If I can't get J19 working, is it possible to use J8? I'm currently using J9 for a DIN interface, but my understanding is that J8 is a hardware SPI interface?

This won't work, as J8 is already used to service the DOUT chain.

And I think that this won't really help to solve this issue.

The problem is maybe the wiring you are using, maybe the frequency of the SCLK output is too high.

I've used 20..30 cm cables in the past as well, but I'm always using ribbon cable.

You could reduce the clock rate by duplicating some MIOS32_SPI2_SET_SCLK_1 and MIOS32_SPI2_SET_SCLK_0 lines in MIOS32_SPI_TransferByte() to check that the cables don't limit the frequency.

Best Regards, Thorsten.

[greevous]

Could someone with a known good STM32 tool chain compile my app.c above (the .h header is just stolen from one of the tutorials) and the #16 aout tutorial and then email the .hex files to me? jrounceville at hotmail.com

I need to split the problem in half, either its my tool chain or my hardware.

I didn't see pre-built versions of the #16 tutorial anywhere, otherwise I would have used that.

[TK.]

You will find the binary under http://www.ucapps.de/tmp/016_aout_modified.zip

After compile I get following message:

-------------------------------------------------------------------------------

Application successfully built for:

Processor: STM32F103RE

Family:    STM32F10x

Board:     MBHP_CORE_STM32

LCD:       clcd

-------------------------------------------------------------------------------

arm-none-eabi-size project_build/project.elf

   text	   data	    bss	    dec	    hex	filename

  44976	     96	  12608	  57680	   e150	project_build/project.elf

[/code]


The code size (listed under "text") is 44976


Do you get exactly the same value?

Then your toolchain installation is ok, and the repository is up-to-date.

 

Best Regards, Thorsten.

[greevous]

Ok, I got this:

-------------------------------------------------------------------------------

Application successfully built for:

Processor: STM32F103RE

Family: STM32F10x

Board: MBHP_CORE_STM32

LCD: clcd

-------------------------------------------------------------------------------

arm-none-eabi-size project_build/project.elf

text data bss dec hex filename

44976 96 12608 57680 e150 project_build/project.elf

So, that probably means this is not a software issue, and is probably a hardware issue.

I did add some delays in the \mios32\STM32F10x\mios32_spi.c (MIOS32_SPI_TransferByte) function inside the SPI software emulation code under the MIOS32_SPI_MODE_CLK0_PHASE0 switch/case, and I when I do that I can see the SC pin going high and low on my oscilloscope. I did notice that "in_data" always ends up being 255, no matter what data is being sent. Is that normal? I don't quite understand the macros that are being executed, so I don't know if that's normal.

So, to recap, I pretty much know I have some kind of hardware issue, but I'm not sure what I need to do next. I tried a different cable and got the same behavior. Is my DAC dead? I'm afraid I don't really understand the SPI protocol well enough to understand what I should be seeing coming into and going out of the TLV5630. Maybe I should switch to my AOUT LC module just to split the hardware problem in half -- if it works with the AOUT LC module, then I know it's the AOUT NG module that's the problem.

TK, I really do appreciate your help thus far. This is turning out to be a lot trickier than I planned.

Edited July 25, 2011 by greevous

[TK.]

I did notice that "in_data" always ends up being 255, no matter what data is being sent. Is that normal?

Yes, the internal pull-up resistor at J19:SI pulls the input to high level - thats normal and you can ignore it as you are not using the serial input anyhow.

So, to recap, I pretty much know I have some kind of hardware issue, but I'm not sure what I need to do next. I tried a different cable and got the same behavior. Is my DAC dead? I'm afraid I don't really understand the SPI protocol well enough to understand what I should be seeing coming into and going out of the TLV5630. Maybe I should switch to my AOUT LC module just to split the hardware problem in half -- if it works with the AOUT LC module, then I know it's the AOUT NG module that's the problem.

I don't think that the AOUT_LC test will give you new input which could help to troubleshoot the AOUT_NG issue.

Could you please describe, how you are testing the AOUT_NG module exactly.

Where do you measure voltages? Did you already try to measure the unamplified voltages directly on the TLV5630 pins?

Which pull-up resistor network are you using at J19 (J32), maybe it could make sense to try another value, e.g. 4*1k instead of 4*10k (or vice versa)

Jumper J26 of the core module is selected for 5V? (the resulting voltage on SC/RC1/SO pins should be ca. 4.4V)

Best Regards, Thorsten.

[greevous]

Could you please describe, how you are testing the AOUT_NG module exactly.

I put my oscilloscope on the output channel pins, and it doesn't change when I turn my encoder (the encoder wheel just increments or decrements a counter that is fed to the AOUT).

I thought maybe it might be a problem in my code, so I just wrote a very simple app that increments a counter from 0 to 65000 and feeds the value to all 8 channels and does an AOUT_Update(). I can see the three SPI pins sending lots of data when I do that, but nothing shows up at the output channels.

Where do you measure voltages? Did you already try to measure the unamplified voltages directly on the TLV5630 pins?

I did check both -- I checked the OUTA, OUTB, OUTC, etc. pins of the TLV5630, and none of them change -- they all sit close to ground. I checked all the GND and VCC pins going into the DAC, and they all seem normal. I also checked the three SPI pins and they match the J1 pins.

Which pull-up resistor network are you using at J19 (J32), maybe it could make sense to try another value, e.g. 4*1k instead of 4*10k (or vice versa)

The resistor network came with the kit from SmashTV... it's marked "5X-1-102LF". When I check pin 1 to any other pin, it measures approximately 1k.

Jumper J26 of the core module is selected for 5V? (the resulting voltage on SC/RC1/SO pins should be ca. 4.4V)

J26 is definitely on 5v. I'll load up the MBSEQ v4 and double check the voltages, but I think they are around 4.4v.

Edited July 25, 2011 by greevous

[greevous]

Does anybody have a known working AOUT NG and STM32 J19 style cable they'd be willing to sell me? I don't seem to be getting anywhere with mine. I think my DAC must be blown -- nothing shows up on the outputs even though I see data streaming in on the inputs (I have no idea if the data is formatted right, but I have no reason to assume it's not). Maybe I fried it when I was soldering it in. It was the first time I soldered an SMD, and although the pins look good under a magnifying glass, maybe I fried it.

[TK.]

I've some additional hints which are worth a try:

• for the case that this isn't properly documented: in distance to other DACs (MBHP_AOUT and MBHP_AOUT_LC), the TLV5630 has to be configured via serial commands before voltage outputs are properly working. This is done in AOUT_IF_Init(). While MBSEQ allows you to call this function again by changing the AOUT interface selection from any module back to AOUT_NG, the tutorial application requires that the core is reset (resp. power-cycled) so that APP_Init() calls AOUT_IF_Init() again.
  
• measure the voltage at the REF pin (pin #16) of the TLV5630.
  It is ca. 0V as long as the chip hasn't been initialized, and 2.05 once AOUT_IF_Init() has been called
  
• another interesting experiment (I'm very interested on the results): configure the J19 pins in push-pull mode. This can be done by adding following defines to your mios32_config.inc file:
  

  
  
  #define AOUT_SPI_OUTPUTS_OD 0
  
  [/code]
  
  
  (recompile the application).
  
  Thereafter change the J26 jumper so that 3.3V are output at J19:Vd - the TLV5630 can work at this voltage range, and by using the pins in push-pull mode the SCLK signal should look "cleaner" than in open drain mode, pulled to 5V.
  
  Even if this doesn't solve the problem, it would be interesting to know if you can see the SCLK on your scope now
  
  
  Best Regards, Thorsten.

[greevous]

Thorsten,

I see +1.05v on pin 16. I also realized that output channels 4,5,6,7,and 8 are actually working, sort of. When I send 64,000 on those channels, they raise to about +5.7v, and are close to +0v when I send 0. For some reason the first three channels (the ones I was testing) don't change from 0v.

Why am I only getting 5.7v instead of approx. 12v on those working channels? I am guessing the three dead channels are burned up in the tlv5630 or something.

I have not tried your other ideas yet.

[TK.]

Before starting with a hypothesis some questions:

I see +1.05v on pin 16.

really 1.05V or 2.05V as expected?

And could you please measure the DAC output voltages directly at the TLV5630?

Channel #1 -> Pin 12

Channel #2 -> Pin 13

Channel #3 -> Pin 14

Channel #4 -> Pin 15

Channel #5 -> Pin 6

Channel #6 -> Pin 7

Channel #7 -> Pin 8

Channel #8 -> Pin 9

Best Regards, Thorsten.

[greevous]

Ok, to eliminate confusion, I decided to take voltage measurements and put them on a picture (attached PDF).

As you can see, pin 16 is floating around 1.04v (TK, you said it should be approx. 2v I believe). Also, as you can see, 5 of the 8 output channels are putting out around 2v, and three of them are putting out almost nothing (OUTA, OUTB, and OUTC). The code that's driving this simply sends 64000 (defined as a u16 variable) to all eight channels when a switch is flipped. I can flip the switch back and forth, and the 5 channels that are working go back and forth between 0v and 2v as measured on the TLV5630.

I don't understand why I'm only getting 1v at pin 16. Also, if I'm nearly maxing the data inputs (64000), shouldn't the output channels on the TLV5630 be close to 5v instead of 2v? Any idea why OUTA, OUTB, and OUTC don't seem to change value and stay close to 0v?

I have not tried any of your suggestions yet. I wanted to give you this information to see if it told you something I'm doing wrong.

AOUT_NG.pdf

[greevous]

I'm not sure how to read the datasheet, but it appears that there are two different modes that the TLV5630 can go into, and one of them runs at 2v on pin 16, and the other runs at 1v on pin 16. Apparently there's some kind of control register you write to to change modes. I'm guessing this is what the AOUT_*_Init() code is supposed to do. Maybe there's a bug in it for the TLV5630 running as I have it configured?

I did stumble across this code. Someone apparently wrote a driver for the TLV5630 that presumably would be similar to the one in MIOS32 (not sure if it's bit banging). I may try to compare them and see if I can see any difference (one difference I noticed already was that the NutDac driver asks for communication speed when doing its initialization -- I'm going to see if I can figure out what it does with this parameter).

Any ideas from TK or anyone else would be greatly appreciated.

Edited July 30, 2011 by greevous

[TK.]

It behaves like the serial transfers are not working correctly (e.g. each word shifted by 1 bit)

Therefore I'm asking you again:

• another interesting experiment (I'm very interested on the results): configure the J19 pins in push-pull mode. This can be done by adding following defines to your mios32_config.inc file:
  

  
  
  #define AOUT_SPI_OUTPUTS_OD 0
  
  [/code]
  
  
  (recompile the application).
  
  Thereafter change the J26 jumper so that 3.3V are output at J19:Vd - the TLV5630 can work at this voltage range, and by using the pins in push-pull mode the SCLK signal should look "cleaner" than in open drain mode, pulled to 5V.
  
  Even if this doesn't solve the problem, it would be interesting to know if you can see the SCLK on your scope now
  
  
  I don't think that trying another driver will really lead to better results.
  
  Please help me to understand the problem at your side by following the instructions that I'm giving you.
  
  Each topic which you are skipping leads to an unclear picture at my side, and this makes it really difficult to help you remotely.
  
  
  Best Regards, Thorsten.

[greevous]

Ok. I'll go do that right now. I wasn't sure if you wanted me to move ahead with your suggestions because there was some confusion on what I was seeing on the pins of the DAC (that's why I created the PDF, to make sure I knew exactly what was happening).

I'll let you know what happens soon.

[greevous]

Alright, I switched the #define AOUT_SPI_OUTPUTS_OD 0 setting (it was in \modules\aout\aout.h), pulled the resistor network from R32, and moved J26 to 3.3v, recompiled my code, pushed it to the core, and measured everything on the TLV5630 after flipping the switch, which sends 64000 to all 8 channels. This is the voltage of every pin on the TLV5630 after sending the 64000:

#1: 0.00v

#2: 0.02v

#3: 0.02v

#4: 3.49v

#5: 3.49v

#6: 1.95v

#7: 1.95v

#8: 1.95v

#9: 1.95v

#10: 0.00v

#11: 3.47v

#12: 0.01v

#13: 0.01v

#14: 0.02v

#15: 1.75v

#16: 0.99v

#17: 3.47v

#18: 0.00v

#19: 0.00v

#20: 3.47v

So I think it is still acting the same way at the 3.3v setting. I can see the clock pulses on pin 5 of J1 when data is being sent. I do know that:

AOUT_IF_Init(0)

returns -4. The documentation says < 0 means the call failed, but I think that might be bogus, because it's returning -4 because 255 is coming back from:

status |= MIOS32_SPI_TransferByte(AOUT_SPI, 0x8 << 4);

and TK said that 255 was a normal return code for MIOS32_SPI_TransferByte()

Thoughts?