Thank you Alex for the suggestion ... I'm browsing all info about Dragon, power, programming .... but still no solution.
I tried to power the board with a powered hub with no success.
A big doubt that I have is the following: looking carefully at what happens when the Dragon tries to interact with the board, I see that first of all the reset line is pulled low. I have checked with a scope and the clock and reset signals look ok.
The problem is: whenever the Dragon actually pulls down reset ... the board actually resets ... and this is just normal, it's like pressing the reset button ... but you can hear the classical sound "bibum - bibim" because actually it's like you have momentaneously disconnected and reconnected USB (the board disappears for a moment from windows devices, and then reappears).
My doubt is how can the Dragon control the board if it behaves this way ... maybe I miss something, but I don't see how the JTAG can take control of the board if this is the sequence!
Any suggestion? Is this (the reset) a behaviour built in the firmaware/bootloader?
I tried to power the board with a powered hub with no success.
A big doubt that I have is the following: looking carefully at what happens when the Dragon tries to interact with the board, I see that first of all the reset line is pulled low. I have checked with a scope and the clock and reset signals look ok.
The problem is: whenever the Dragon actually pulls down reset ... the board actually resets ... and this is just normal, it's like pressing the reset button ... but you can hear the classical sound "bibum - bibim" because actually it's like you have momentaneously disconnected and reconnected USB (the board disappears for a moment from windows devices, and then reappears).
My doubt is how can the Dragon control the board if it behaves this way ... maybe I miss something, but I don't see how the JTAG can take control of the board if this is the sequence!
Any suggestion? Is this (the reset) a behaviour built in the firmaware/bootloader?
The power should be OK. Both the board and the Dragon are connected to two different USB ports on a laptop. I tried different setups with no change.
The reset happens when I launch any command on the Dragon, which actually pulls the reset line on JTAG low. I think this is normal, or not?
Anyway, when connecting an X-plained board in place of the AB 1.1 everything works ok: the reset line is pulled low, and the JTAG works ... with AB 1.1 the board resets, and the Dragon reports an error saying the it has troubles reading the JTAG id ....
The reset happens when I launch any command on the Dragon, which actually pulls the reset line on JTAG low. I think this is normal, or not?
Anyway, when connecting an X-plained board in place of the AB 1.1 everything works ok: the reset line is pulled low, and the JTAG works ... with AB 1.1 the board resets, and the Dragon reports an error saying the it has troubles reading the JTAG id ....
Another doubt: browsing the code I see there is a section where the CPU tries to understand what's the cause of the reset ... brown out detector, actual reset button and so on ...
There's nothing that deals with JTAG. This code is standard or custom for the board?
From what I understand if it's executed ... it's normal that the board resets. Maybe it's another stupid question, but shouldn't be there some check on if a JTAG session is starting?
There's nothing that deals with JTAG. This code is standard or custom for the board?
From what I understand if it's executed ... it's normal that the board resets. Maybe it's another stupid question, but shouldn't be there some check on if a JTAG session is starting?
Maybe try disconnecting the USB from the audio-widget. Just power the Dragon and connect to the JTAG connector. In AVR32 Studio there is an option to supply power from the JTAG to the uC - make sure it is 3v3 (not 5V).
I have been using JTAGICE MkII with the sdr-widget (a sister project of the audio-widget) with no issues. I have not tried with the audio-widget though so it may be different.
You should be able to completely erase the flash on the uC and install a new bootloader and change the fuses (with the JTAGICE MkII). Don't know about the Dragon
Alex
I have been using JTAGICE MkII with the sdr-widget (a sister project of the audio-widget) with no issues. I have not tried with the audio-widget though so it may be different.
You should be able to completely erase the flash on the uC and install a new bootloader and change the fuses (with the JTAGICE MkII). Don't know about the Dragon
Alex
I'm unable to find where I can set the Dragon to supply power, I suppose it's always on? VTREF pin is connected to VDD_3V3, so it should be so.
Anyway, after my last attempts I'm stuck in a very strange situation, with firmware of May 29 installed, working in UAC2 only, and unable to put the board in DFU mode any more. I tried in every mode, but without success.
Is there any other sequence that I can try besides keeping Prog button down and hitting reset?
Anyway, after my last attempts I'm stuck in a very strange situation, with firmware of May 29 installed, working in UAC2 only, and unable to put the board in DFU mode any more. I tried in every mode, but without success.
Is there any other sequence that I can try besides keeping Prog button down and hitting reset?
My WidgetControl.py screenshot looks like this:
Screenshot-2012-06-10-WidgetControl.png - sdr-widget - Screenshot of WidgetControl for Borge's AB1.1 - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
You should be able to change from uac2_audio to uac1_audio etc.
If you are not able to change with the PRG/RESET button presses then there may be something wrong with the switches. Check their continuity with the uC pins
Alex
Screenshot-2012-06-10-WidgetControl.png - sdr-widget - Screenshot of WidgetControl for Borge's AB1.1 - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
You should be able to change from uac2_audio to uac1_audio etc.
If you are not able to change with the PRG/RESET button presses then there may be something wrong with the switches. Check their continuity with the uC pins
Alex
The Reset and Prog button signals should see 10kOhm to +3.3V when not pressed, and 0Ohm to GND when pressed.
Which colour is your module? On the red ones I made a BOM mistake and specified 10nF capacitors for the pull-up resistors. This is something I fixed and then tested on each module which went out. What you are describing sounds a bit like what happened the first time I powered on a module like that. So if your module is red, check if R1303 and R1304 are indeed resistors.
Børge
Which colour is your module? On the red ones I made a BOM mistake and specified 10nF capacitors for the pull-up resistors. This is something I fixed and then tested on each module which went out. What you are describing sounds a bit like what happened the first time I powered on a module like that. So if your module is red, check if R1303 and R1304 are indeed resistors.
Børge
Attachments
I have measured AB-ES9023. Is measured with MOTU UltraLite MK3.
Intermodulation measurements are similar or better than AK4430 presented by 1audio of the post 1384.http://www.diyaudio.com/forums/digi...sb-interface-audio-widget-28.html#post2950288I think the DAC ES9023 of 1audio may have a problem.
also I put jitter measures at 44,100 kHz.
(I do not have Wav Jtest file to measure at 48,000 kHz.)
An externally hosted image should be here but it was not working when we last tested it.
Intermodulation measurements are similar or better than AK4430 presented by 1audio of the post 1384.http://www.diyaudio.com/forums/digi...sb-interface-audio-widget-28.html#post2950288I think the DAC ES9023 of 1audio may have a problem.
also I put jitter measures at 44,100 kHz.
(I do not have Wav Jtest file to measure at 48,000 kHz.)
An externally hosted image should be here but it was not working when we last tested it.
PM me and I'll send you my test files.
I have not been impressed by the ESS dacs and the measurements met spec so I was not expecting more. I'll redo the IM and THD measurements with the latest firmware and post them. I also have a proto from Borge with a different USB interface I can plot for comparison. Perhaps the chip is broken or ???
Most of the fir in the IM plot is from the motu or a grounding problem between it and the AB1.1. If you can upgrade the clocks or improve the bypassing you should see it reduce or go away.
I have not been impressed by the ESS dacs and the measurements met spec so I was not expecting more. I'll redo the IM and THD measurements with the latest firmware and post them. I also have a proto from Borge with a different USB interface I can plot for comparison. Perhaps the chip is broken or ???
Most of the fir in the IM plot is from the motu or a grounding problem between it and the AB1.1. If you can upgrade the clocks or improve the bypassing you should see it reduce or go away.
Hi Borge, hi Alex,
after a lot of attempts I was able to revive the board, loaded the latest firmware with DFU and now it's working (in UAC2). I'll leave it this way to avoid
further problems.
Anyway, two details.
- My module is yellow.
- I removed the pullup resistor and capacitor to ground on reset line, the Atmel datasheet states that there is a pullup internal to the chip on RESET_N, so they should not be necessary (and my idea was that they were interfering with the reset signal coming form the Dragon). I got no change, the reset works equally well without them in place, and the Dragon is not working in the same way.
- My final idea is that there is something in the code or fuses that prevents the JTAG resent signal to be interpreted correctly (the chip should understand that it's the start of a JTAG / ISP session, and instead it resets as usual). I don't believe that a JTAG ICE II would improve things, but if you confirm that the JTAG is working on other installations I'll try to find one to see if it's better. If nobody has recently used it with JTAG ... maybe it's a waste of time, maybe the code has changed since your last successful attempts.
Anyway, thank you to everybody for your support.
after a lot of attempts I was able to revive the board, loaded the latest firmware with DFU and now it's working (in UAC2). I'll leave it this way to avoid
further problems.
Anyway, two details.
- My module is yellow.
- I removed the pullup resistor and capacitor to ground on reset line, the Atmel datasheet states that there is a pullup internal to the chip on RESET_N, so they should not be necessary (and my idea was that they were interfering with the reset signal coming form the Dragon). I got no change, the reset works equally well without them in place, and the Dragon is not working in the same way.
- My final idea is that there is something in the code or fuses that prevents the JTAG resent signal to be interpreted correctly (the chip should understand that it's the start of a JTAG / ISP session, and instead it resets as usual). I don't believe that a JTAG ICE II would improve things, but if you confirm that the JTAG is working on other installations I'll try to find one to see if it's better. If nobody has recently used it with JTAG ... maybe it's a waste of time, maybe the code has changed since your last successful attempts.
Anyway, thank you to everybody for your support.
1Audio. PM send.
Do not know why, my AB.1.1 makes sometimes measures similar to yours, but are fixed by simply moving the connectors or the DAC. There seems to be a problem for the ground.
The measurement of intermodulation, The MOTU card is not bad mass, only occurs when I measuring the test signal of 19 and 20 kHz. If you look is periodic noise, its not groud noise. I guess the charge pump power requirement is excessive, or there is interference between tracks, or would affect the external power.
With a signal of 1 kHz, for example, the ground noise is much cleaner.
The MOTU has no background noise as low as your system but is not bad, you can make measurements with a dynamic range of 140 dB by Line Input.
The microphone input is not very good.
The bad notice is that it only has 44.100 crystal and therefore only make good measurements or recordings at 44,100 Hz.and multiple.
48,000 Hz synthesized, and are bad measures and recording at this frecuence and multiple.
Do not know why, my AB.1.1 makes sometimes measures similar to yours, but are fixed by simply moving the connectors or the DAC. There seems to be a problem for the ground.
The measurement of intermodulation, The MOTU card is not bad mass, only occurs when I measuring the test signal of 19 and 20 kHz. If you look is periodic noise, its not groud noise. I guess the charge pump power requirement is excessive, or there is interference between tracks, or would affect the external power.
With a signal of 1 kHz, for example, the ground noise is much cleaner.
The MOTU has no background noise as low as your system but is not bad, you can make measurements with a dynamic range of 140 dB by Line Input.
The microphone input is not very good.
The bad notice is that it only has 44.100 crystal and therefore only make good measurements or recordings at 44,100 Hz.and multiple.
48,000 Hz synthesized, and are bad measures and recording at this frecuence and multiple.
I'm sending you the files. Let me know if it all works.
I usually try to measure with a different non-synced sample rates so there are no hidden artifacts. The measurements are tedious to get right.
USB has a 1 KHz or 4 KHz update rate for the data transfers. It can cause some jitter artifacts as an interaction between the different clocks. Measuring with the same computer that is generating the signals can further challenge the measurement process.
I usually try to measure with a different non-synced sample rates so there are no hidden artifacts. The measurements are tedious to get right.
USB has a 1 KHz or 4 KHz update rate for the data transfers. It can cause some jitter artifacts as an interaction between the different clocks. Measuring with the same computer that is generating the signals can further challenge the measurement process.
