Hi OJG,
The STM32 has only one SPI/I2S port and looks very limited in capability. Eg see page 686 of datasheet that the register is 16 bits so you need two reads for 24/32 bit samples. Also pins used for full duplex instead if dedicated i2s input or output. You cannot do 8 channels with this chip.
We actually found one that can do multichannel i2s. It is the TMS320C5535 recommended by rsdio. It has 4 I2s ports so 8 channels.
The only problem is that it is BGA so difficult for DIY.
Alex
The STM32 has only one SPI/I2S port and looks very limited in capability. Eg see page 686 of datasheet that the register is 16 bits so you need two reads for 24/32 bit samples. Also pins used for full duplex instead if dedicated i2s input or output. You cannot do 8 channels with this chip.
We actually found one that can do multichannel i2s. It is the TMS320C5535 recommended by rsdio. It has 4 I2s ports so 8 channels.
The only problem is that it is BGA so difficult for DIY.
Alex
There are other processors in the C55xx family that are available in LQFP packaging. Starting with the lowest cost, they are the C5502, C5506, C5503, C5507 and C5509A. Each has 3 I2S ports and 1 I2C port. Three I2S ports may seem like a limitation, but read on...
One question I have is whether standard audio DACs can handle multiple chips on the same serial bus. My C5506 design uses 2 I2S ports, each connected to an 8-channel ADS chip, with a total sample rate of 2 MHz. That's 1 MHz per I2S port, or 125 kHz per channel at 8 channels.
Considering the bandwidth needed, I think it should be possible to attach more than one DAC chip to the same I2S port and use various chip select or other addressing schemes to send 4 or more channels on the same port. The McBSP peripherals on the TMS320 can certainly handle multiple device addressing on a single port, but so far I have not investigated the I2S protocol and how it is implemented on specific chips that folks here are interested in using. It's certainly possible that multi-chip addressing might not be compatible. However, there might be a way to use a small FPGA to split out a single port to drive multiple DAC chips, perhaps by alternating the BCLK or other signals.
Another possibility are those 6-channel and 8-channel DAC chips from the likes of Asahi Kasei, which surely can handle more than 2 channels on a single I2S port. Looking around at the data sheets I have on hand, I see:
4-channel: AK4682, AK4683
6-channel: AK4346, AK4586, AK4591, AK4626A
8-channel: AK4588, AK4589, AK4628A
I'm sure that other chip makers have audiophile quality DAC chips that go beyond stereo, and my whole point here is that 3 I2S ports would not feel cramped with multichannel DACs, and then you can have the LQFP TMS320 DSP.
By the way, I'm currently working with super high samples rates like 125 MHz, so the DAC chips I'm using from Texas Instruments are nowhere near 24-bit. I'm just reeling off the AK parts I happen to have researched before.
Thanks rsdio for the information.
We are designing a USB-i2S module that can work with different DAC's. Even our 2 channel interface (based on the Atmel) is now driving CS4344, ES9023, and soon the TI 32 bit DAC, with ES9018 and WM etc coming.
There are chips like the ES9018 that can be connected with TDM for miltichannels. However, even with these chips we want to run them in parellel or even mono mode for best performance. Nothing beats 4x i2s ports
Alex
We are designing a USB-i2S module that can work with different DAC's. Even our 2 channel interface (based on the Atmel) is now driving CS4344, ES9023, and soon the TI 32 bit DAC, with ES9018 and WM etc coming.
There are chips like the ES9018 that can be connected with TDM for miltichannels. However, even with these chips we want to run them in parellel or even mono mode for best performance. Nothing beats 4x i2s ports
Alex
Yeah, my reply was rather long, but the short version is that you can have 4 I2S with BGA or 3 I2S with LQFP. Depending upon your needs versus the costs, pick your option.
By the way, I've been reading the BGA has problems with the PCB flexes. Would that make BGA a particularly bad choice for DIY? Most products do not see any PCB handling after manufacturing, but a DIY board might actually end up with failed BGA connections. I suppose that if you really need 4 I2S ports then you do have the option of making the PCB really thick, like 125 mil or anything over 62 mil. That might alleviate some of the BGA problems, but not the expense.
By the way, I've been reading the BGA has problems with the PCB flexes. Would that make BGA a particularly bad choice for DIY? Most products do not see any PCB handling after manufacturing, but a DIY board might actually end up with failed BGA connections. I suppose that if you really need 4 I2S ports then you do have the option of making the PCB really thick, like 125 mil or anything over 62 mil. That might alleviate some of the BGA problems, but not the expense.
Hi there,
I've tried upgrading firmware on my AB11 DAC and the device end up bricked. It's very strange, because I've upgraded AB11 few times before with a success following exactly the same steps:
1) Download latest firmware to c:\Program Files\Atmel\Flip 3.4.2\bin directory
2) In CMD window, go to c:\Program Files\Atmel\Flip 3.4.2\bin directory
3) Connect AB11, press the PRG button down, and keeping it down, press RESET button once.
4) Enter command 'batchisp -device at32uc3a3256 -hardware usb -operation erase f memory flash blankcheck loadbuffer firmware.elf program verify start reset 0'
Above procedure worked fine before, but now it stopped at Erasing step, displaying 'FAIL could not read from USB device' message. In that moment Windows detects new unknown device for which I can't install any drivers. I tried pressing Ignore, Retry many times, as well as repeat the whole procedure, but no luck.
Enclosed is the screenshot with the error: http://img854.imageshack.us/img854/4698/errorjl.jpg
Many thanks for your help
Best regards,
Marcin
I've tried upgrading firmware on my AB11 DAC and the device end up bricked. It's very strange, because I've upgraded AB11 few times before with a success following exactly the same steps:
1) Download latest firmware to c:\Program Files\Atmel\Flip 3.4.2\bin directory
2) In CMD window, go to c:\Program Files\Atmel\Flip 3.4.2\bin directory
3) Connect AB11, press the PRG button down, and keeping it down, press RESET button once.
4) Enter command 'batchisp -device at32uc3a3256 -hardware usb -operation erase f memory flash blankcheck loadbuffer firmware.elf program verify start reset 0'
Above procedure worked fine before, but now it stopped at Erasing step, displaying 'FAIL could not read from USB device' message. In that moment Windows detects new unknown device for which I can't install any drivers. I tried pressing Ignore, Retry many times, as well as repeat the whole procedure, but no luck.
Enclosed is the screenshot with the error: http://img854.imageshack.us/img854/4698/errorjl.jpg
Many thanks for your help
Best regards,
Marcin
Yes, it has only one I2S port, but could possibly be capable of TDM for multichannel although this limits the selection of DACs and ADCs quite a bit.
The 16-bit port register shouldn't be a problem as long as the DMA can fill it with data fast enough.
I would think that a modern 32-bit general purpose processor such as the AVR32 or ARM would be better at USB endpoint duty than an old 16-bit DSP architecture such as the C55x, but it would be great if you could prove me wrong
Br,
OJG
Hi Marcin,
In the Code page download area there is this Linux program:
dfu-programmer-0.5.4.tar.gz
If you know Linux (or can find someone to help you), you can build the dfu-programmer in a Linux PC and then run the following script.
We have found that sometimes Windows mysteriously fails to flash devices, but under Linux it works. After successful flashing under Linux, it then mysteriously becomes flashable under Windows again (somethimes).
If you don't know Linux you can't do this - it is rather complicated to a new Linux user :-(
Alex
The program_widget script:
#!/bin/bash
##
## program the sdr-widget under linux as of Sun May 1, 2011
## accepts either a widget.elf file or a widget.hex file
##
echo program-widget with $1
[[ -z $1 ]] && echo "no file specified to program-widget" && exit 1
[[ ! -f $1 ]] && echo "no such file '$1'" && exit 1
case $1 in
*.elf)
hex=/tmp/`basename $1 .elf`.hex
objcopy -O ihex $1 $hex && \
dfu-programmer at32uc3a3256 erase --debug 6 && \
dfu-programmer at32uc3a3256 flash --suppress-bootloader-mem $hex --debug 6 && \
dfu-programmer at32uc3a3256 reset --debug 4 && \
rm $hex && \
exit 0
;;
*.hex)
dfu-programmer at32uc3a3256 erase --debug 6 && \
dfu-programmer at32uc3a3256 flash --suppress-bootloader-mem $1 --debug 6 && \
dfu-programmer at32uc3a3256 reset --debug 4 && \
exit 0
;;
*)
echo unrecognized file format for programming: $1
exit 1
esac
In the Code page download area there is this Linux program:
dfu-programmer-0.5.4.tar.gz
If you know Linux (or can find someone to help you), you can build the dfu-programmer in a Linux PC and then run the following script.
We have found that sometimes Windows mysteriously fails to flash devices, but under Linux it works. After successful flashing under Linux, it then mysteriously becomes flashable under Windows again (somethimes).
If you don't know Linux you can't do this - it is rather complicated to a new Linux user :-(
Alex
The program_widget script:
#!/bin/bash
##
## program the sdr-widget under linux as of Sun May 1, 2011
## accepts either a widget.elf file or a widget.hex file
##
echo program-widget with $1
[[ -z $1 ]] && echo "no file specified to program-widget" && exit 1
[[ ! -f $1 ]] && echo "no such file '$1'" && exit 1
case $1 in
*.elf)
hex=/tmp/`basename $1 .elf`.hex
objcopy -O ihex $1 $hex && \
dfu-programmer at32uc3a3256 erase --debug 6 && \
dfu-programmer at32uc3a3256 flash --suppress-bootloader-mem $hex --debug 6 && \
dfu-programmer at32uc3a3256 reset --debug 4 && \
rm $hex && \
exit 0
;;
*.hex)
dfu-programmer at32uc3a3256 erase --debug 6 && \
dfu-programmer at32uc3a3256 flash --suppress-bootloader-mem $1 --debug 6 && \
dfu-programmer at32uc3a3256 reset --debug 4 && \
exit 0
;;
*)
echo unrecognized file format for programming: $1
exit 1
esac
Hi Alex, great job !
Do you mean you're cooking a module abble to drive our external DAC's - such as Opus or others - that could be feed by I2S stream ?
Answer me yes, please
No offense, but have you actually written USB firmware? USB is an 8-bit protocol, so even on those low-power 16-bit DSP chips, there is a necessary translation from the 16-bit native word size to 8-bit data for USB. There really is no advantage in 32-bit processing for USB. All processors become slightly less efficient when dealing with 8-bit USB data.I would think that a modern 32-bit general purpose processor such as the AVR32 or ARM would be better at USB endpoint duty than an old 16-bit DSP architecture such as the C55x, but it would be great if you could prove me wrong
Granted, so far we've only been discussing C55x options, but there are also C2000, C6000 and ARM+DSP hybrids. It might be worth a quick search to see if any of the 32-bit varieties have 4 I2S ports.
Another point: Not only are there 32-bit members of the TMS320 family outside the C55x, but keep in mind that the C55x has 32-bit memory interfacing as on option on certain parts, and all members have 32-bit data memory addressing modes along with 40-bit registers. I've certainly written code to handle building USB packets with 40-bit processing.
I checked my board today and didn't find any obvious reasons for failure except the fact that the MCU might be fried.
It happily now shows up as an ATMEL AT32UC3A device in the devicemanager.
Tried to program it again:
1: Press program and hold it - give reset one push - release program.
2: It refreshed the devicemanager - still shown as an ATMEL AT32UC3A device.
3: Program:
C:\Program Files\Atmel\Flip 3.4.3\bin>prog demo_flashyblinky.elf
C:\Program Files\Atmel\Flip 3.4.3\bin>batchisp -device at32uc3a3256 -hardware us
b -operation erase f memory flash blankcheck loadbuffer demo_flashyblinky.elf pr
ogram verify start reset 0
Running batchisp 1.2.5 on Sat Nov 19 12:31:02 2011
AT32UC3A3256 - USB - USB/DFU
Device selection....................... PASS
Hardware selection..................... PASS
Opening port........................... PASS
Reading Bootloader version............. PASS 1.0.3
Erasing................................ FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Selecting FLASH........................ PASS
Blank checking......................... FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Parsing ELF file....................... PASS demo_flashyblinky.elf
WARNING: The user program and the bootloader overlap!
Programming memory..................... FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Verifying memory....................... FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Starting Application................... PASS RESET 0
Summary: Total 11 Passed 7 Failed 4
C:\Program Files\Atmel\Flip 3.4.3\bin>
---
After these lines:
Device selection....................... PASS
Hardware selection..................... PASS
Opening port........................... PASS
Reading Bootloader version............. PASS 1.0.3
It vanishes from the devicemanager and Windows claims it fond an unknown device...
There seems to be some communication between the MCU and PC since it was able to read the bootloader version???
I better get a Linuxbox running.
Brgds
It happily now shows up as an ATMEL AT32UC3A device in the devicemanager.
Tried to program it again:
1: Press program and hold it - give reset one push - release program.
2: It refreshed the devicemanager - still shown as an ATMEL AT32UC3A device.
3: Program:
C:\Program Files\Atmel\Flip 3.4.3\bin>prog demo_flashyblinky.elf
C:\Program Files\Atmel\Flip 3.4.3\bin>batchisp -device at32uc3a3256 -hardware us
b -operation erase f memory flash blankcheck loadbuffer demo_flashyblinky.elf pr
ogram verify start reset 0
Running batchisp 1.2.5 on Sat Nov 19 12:31:02 2011
AT32UC3A3256 - USB - USB/DFU
Device selection....................... PASS
Hardware selection..................... PASS
Opening port........................... PASS
Reading Bootloader version............. PASS 1.0.3
Erasing................................ FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Selecting FLASH........................ PASS
Blank checking......................... FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Parsing ELF file....................... PASS demo_flashyblinky.elf
WARNING: The user program and the bootloader overlap!
Programming memory..................... FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Verifying memory....................... FAIL Could not read from USB device.
(A)bort, (R)etry, (I)gnore ? i
Starting Application................... PASS RESET 0
Summary: Total 11 Passed 7 Failed 4
C:\Program Files\Atmel\Flip 3.4.3\bin>
---
After these lines:
Device selection....................... PASS
Hardware selection..................... PASS
Opening port........................... PASS
Reading Bootloader version............. PASS 1.0.3
It vanishes from the devicemanager and Windows claims it fond an unknown device...
There seems to be some communication between the MCU and PC since it was able to read the bootloader version???
I better get a Linuxbox running.
Brgds
By creating a new AVR target in AVR32Studio I was able to communicate with the MCU. I did a readout of all memory and the fuses so it can communicate.
I believe the bootloader is trashed and can't find how to refresh it...
By the way - when programing shouldn't there be an offset so that it doesn't start writing at 0x0?
Brgds
BTW: Vista didn't work either - just the same behaviour as XP
I believe the bootloader is trashed and can't find how to refresh it...
By the way - when programing shouldn't there be an offset so that it doesn't start writing at 0x0?
Brgds
BTW: Vista didn't work either - just the same behaviour as XP
Last edited:
1. The only way to flash a new bootloader is to use JTAG-ICE mk II.
2. The flashing of user firmware starts at 0. The firmware image is such that memory portion where the bootloader is occupied by a "trampoline" routine.
So it works on a chip with OR without the bootloader.
a. With the bootloader - the bootloader CANNOT be overwritten by flashing software as it is hardware protected. So the flashing software gives a warning only.
b. in a chip without the bootloader, the whole fiware image is flashed. The trampoline code just redirects the program flow to the correct entry point of the program.
If you are curious you might like to google for atmel avr32 bootloader and JTAG-ICE mk II info as this is a bit off topic in diyaudio
Alex
2. The flashing of user firmware starts at 0. The firmware image is such that memory portion where the bootloader is occupied by a "trampoline" routine.
So it works on a chip with OR without the bootloader.
a. With the bootloader - the bootloader CANNOT be overwritten by flashing software as it is hardware protected. So the flashing software gives a warning only.
b. in a chip without the bootloader, the whole fiware image is flashed. The trampoline code just redirects the program flow to the correct entry point of the program.
If you are curious you might like to google for atmel avr32 bootloader and JTAG-ICE mk II info as this is a bit off topic in diyaudio
Alex
Hi Marcingps.
Yes I noticed that. To me I feels as the MCU doesn't give access to the flash area. I have successfully read out the fuses part but thats all. I tought I succeeded to read out the whole memory but I'm not shure about what I did since I cant find the hex file. Most probably it failed. Hmmm, I really don't want to give up on this so I have two options - either to buy a new MCU with a fresh bootloader and take the hassle of replacing it or buy a JTAG programmer (I have no idea of the price for one of them...).
If I'll give up I'll hope that Borges have a AB1-1 ready for me ;-)
Brgds and good luck.
Yes I noticed that. To me I feels as the MCU doesn't give access to the flash area. I have successfully read out the fuses part but thats all. I tought I succeeded to read out the whole memory but I'm not shure about what I did since I cant find the hex file. Most probably it failed. Hmmm, I really don't want to give up on this so I have two options - either to buy a new MCU with a fresh bootloader and take the hassle of replacing it or buy a JTAG programmer (I have no idea of the price for one of them...).
If I'll give up I'll hope that Borges have a AB1-1 ready for me ;-)
Brgds and good luck.
Hi Turbon & Marcingps,
JTAG-ICE Mk II is US$300 from Atmel. I use a clone at US$150 free shipping worldwide:
http://www.pic16.com/en/wzcapi/avrjtagicemkii.htmI
The fact that the Atmel cpu can tell you the version number of the bootloader means there IS communication between the cpu and the PC at least during the initial stages of communication.
The other hardware part to check is the 12Mhz Xtal. If you have a scanner scan for 12Mhz near the Xtal. The Atmel cpu starts up with the internal RC oscillator and switches to the Xtal oscillator subsequently. The 12Mhz Xtal is needed for accurate USB communications.
demo_flashblinky uses the internal RC oscillator only. Since it has been reported to work in one of your boards before it may be a clue to indicate a problem with the 12Mhz XO.
Check the orientation of the XO. I last soldered the board quite some time ago, but I seem to remember that it is a 4 pin device. Only two of the pins are active. So it may be oriented 90 degrees off.
Also worth trying is the Linux flashing.
Alex
JTAG-ICE Mk II is US$300 from Atmel. I use a clone at US$150 free shipping worldwide:
http://www.pic16.com/en/wzcapi/avrjtagicemkii.htmI
The fact that the Atmel cpu can tell you the version number of the bootloader means there IS communication between the cpu and the PC at least during the initial stages of communication.
The other hardware part to check is the 12Mhz Xtal. If you have a scanner scan for 12Mhz near the Xtal. The Atmel cpu starts up with the internal RC oscillator and switches to the Xtal oscillator subsequently. The 12Mhz Xtal is needed for accurate USB communications.
demo_flashblinky uses the internal RC oscillator only. Since it has been reported to work in one of your boards before it may be a clue to indicate a problem with the 12Mhz XO.
Check the orientation of the XO. I last soldered the board quite some time ago, but I seem to remember that it is a 4 pin device. Only two of the pins are active. So it may be oriented 90 degrees off.
Also worth trying is the Linux flashing.
Alex