Device won't work under the control of the debugger

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a debugging issue that you guys may be able to shed some light on. The device is an audio player on a custom PCB. It receives commands from a radio link via UART and plays audio files from an SD card based upon the commands it receives. The controller is a 1284P which reads mp3 files from the SD card and stores the data in a buffer. It then feeds the data via SPI to a VS1063 audio processor that decodes and plays it. 

 

The problem I am having is that this system will not work under the control of AS7's debugger, but it works fine running by itself. When it is running free, it will play a file to the end. However, when I start a debugging session(JTAG ICE), it sends the data to the DSP, but the DSP won't play it. I suspect that the problem is related to timing. The DSP calls for data by pulling up its DATA REQUIRED line that is connected to a GPIO pin on the 1284P. The 1284P waits for the DATA REQUIRED line to go high and then sends 32 bytes to the DSP. It repeats this till the end of file. When its free running, the DSP calls for data every few milliseconds from the beginning to the end of the file. But when I start a debugging session, there is no activity at all on the DATA REQUIRED line. 

 

I would not think that the DSP would know whether there was a debugging session going on or not. Whatever the cause, I notice that once I start a debugging session, I have to reboot the MCU to get it running normally again.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are any of the JTAG pins used by the system by any chance? I know silly question but who knows. laugh

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, John. I can post the schematic and the code, if anyone thinks that will help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It MAY help to spot something.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

have you checked start-up conditions on the SPI interface?

long shot, but if there is some sort of activity in the SPI lines prior before the Mega reset is released, it might be accidentally sending out some bogus data as it might think the ISP programmer is connected......

even might be that because of the debugging going on the start condition for the SPI lines is wrong....

all should be simply ruled out when you connect a scope before any power applied and then measure the start-up behavior of these lines with and without the debugger attached.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Somewhere in AS7 there is an option that says whether interrupts continue while stopped. I have a sneaking suspicion this needs to be set the other way.

 

Without seeing the code and the way it interacts with the VLSI it's quite difficult to know though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the schematic and the code

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I searched for the option Clawson referred to in AS7 and on the MC web site -- w/o success. Does anyone else have any info on this? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No pullups on the spi chip select lines. This can cause weird startup problems especially when debug delays the port initialization.
As an aside, you have a cli() and sei() in your usart rxd isr. This may have nasty unintended consequences. These surround a global var. firstly the avr disables interrupts when it enters an isr. Secondly, the global is not needed.

 

As an another aside, there's no transient protection on the dc input nor ESD protection for Q1,3.

Last Edited: Fri. May 24, 2019 - 12:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Kartman, comments appreciated. I bodged in a couple of pull up on the CS lines to see if that affected anything. It didn't.

I am doing a revision to this PCB when I get the kinks out, so I do get another bit at the apple. Also, this is a four layer board. I have discovered that, that alone, mitigates lots of ESD/EMI, RFI problems.