FX3 J-Link Bad JTAG Communication

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ThAl_4704151
Level 4
Level 4
25 sign-ins 25 replies posted 10 replies posted

Hello all,

I've been having some trouble running my application again after hitting a breakpoint, but only when it's in a certain spot.

I do CyU3PDeviceInit(), CyU3PDeviceConfigureIOMatrix(), and CyU3PGpioInit() before starting the CyU3PKernelEntry() in main. The application define function sets up URT and creates a thread. In that thread, the first thing I do is call a function to set up GPIF-II plus a couple of GPIO pins. I have a breakpoint set at the end of that function so that I can start up the other microcontroller that's supposed to be listening to one of those pins. It doesn't get set until later, but breaking later messes up the timing for USB.

When I try to run the application after stopping there, I get "ERROR: Bad JTAG communication: Write to IR: Expected 0x1, got 0x0 (TAP Command : 2) @ Off 0x5.".

I saw https://community.cypress.com/docs/DOC-18696, but trying the solution presented doesn't seem to have worked, and after watching the register mentioned there, it stays at the value I set it in the debug configuration, so it doesn't appear that the clock speed is changing as the aforementioned article describes. I'm also able to set breakpoints in other places in my program that behave normally. That is, they break and continue when I tell them to.

Here's the GPIO/GPIF-II initialization function. As I mentioned, it's the first thing that gets called by the main thread.

void gpio_entry(){

     CyU3PGpioSimpleConfig_t config;

     CyU3PReturnStatus_t status;

     CyU3PPibClock_t pibClock;

     // Configure GPIO_IS_PS as an input, since it's how the 8051 tells us

     config.driveHighEn = CyFalse;

     config.driveLowEn = CyFalse;

     config.inputEn = CyTrue;

     config.intrMode = CY_U3P_GPIO_NO_INTR;

     config.outValue = CyFalse; // Not an output, so who cares?

     status = CyU3PGpioSetSimpleConfig(GPIO_IS_PS, &config);

     if (status != CY_U3P_SUCCESS){

          errorLoop();

     }

     // Configure GPIO_READY as an output, since it tells the 8051 when we're ready.

     config.driveHighEn = CyTrue;

     config.driveLowEn = CyTrue;

     config.inputEn = CyFalse;

     config.intrMode = CY_U3P_GPIO_NO_INTR;

     config.outValue = CyFalse;

     status = CyU3PGpioSetSimpleConfig(GPIO_READY, &config);

     if (status != CY_U3P_SUCCESS){

          errorLoop();

     }

     // Configure GPIO_SEND_INTERRUPT as an output, since it send out an interrupt signal to the 8051 when we have data

     config.driveHighEn = CyTrue;

     config.driveLowEn = CyTrue;

     config.inputEn = CyFalse;

     config.intrMode = CY_U3P_GPIO_NO_INTR;

     config.outValue = CyTrue;

     status = CyU3PGpioSetSimpleConfig(GPIO_SEND_INTERRUPT, &config);

     if (status != CY_U3P_SUCCESS){

          errorLoop();

     }

     extern uint32_t interruptInitTicks;

     interruptInitTicks = CyU3PGetTime();

     /* Initialize the p-port block. */

     pibClock.clkDiv = 2;

     pibClock.clkSrc = CY_U3P_SYS_CLK;

     pibClock.isHalfDiv = CyFalse;

     /* Enable DLL for async GPIF */

     pibClock.isDllEnable = CyTrue;

     status = CyU3PPibInit(CyTrue, &pibClock);

     if (status != CY_U3P_SUCCESS)

     {

          CyU3PDebugPrint (4, "P-port Initialization failed, Error Code = %d\n",status);

          errorLoop();

     }

     /* Load the GPIF configuration for Slave FIFO async mode. */

     status = CyU3PGpifLoad (&CyFxGpifConfig);

     if (status != CY_U3P_SUCCESS)

     {

          CyU3PDebugPrint (4, "CyU3PGpifLoad failed, Error Code = %d\n",status);

          errorLoop();

     }

     /* Start the state machine. */

     status = CyU3PGpifSMStart (RESET, ALPHA_RESET);

     if (status != CY_U3P_SUCCESS)

     {

          CyU3PDebugPrint (4, "CyU3PGpifSMStart failed, Error Code = %d\n",status);

          errorLoop();

     }

     // Wait for a few ms to give the 8051 a window in which to start listening to the interrupt pins before anything interesting is sent

     CyU3PThreadSleep(INIT_WINDOW_MS);

     return;

}

The very last line of the function is where I have my breakpoint set. Right before the return. I've also tried it right before the sleep function.

GPIO_IS_PS  is gpio[25]

GPIO_READY is gpio[26]

GPIO_SEND_INTERRUPT is gpio[27]

GPIF-II uses GPIO[0:9] for address and data, and GPIO[17:22] and GPIO[24] for other signals.

INIT_WINDOW_MS is 100 for now, but I'll probably adjust that later.

Have I done something wrong? Is this something I need to fix on the FX3? In the IDE?

If we can rule those out and it looks like it's a hardware problem, I can talk to the guy who worked on the board, but I'd like to know that I've covered my bases, and ideally, I'd like to find more information for him to go on.

More generally, I'd appreciate any information that could shed some light on the problem.

Thanks for your help!

EDIT: Something else I observed today was that if I start the program up again immediately after it hits the breakpoint, I can continue running the program. I only run into trouble if I take the time to switch to my other IDE and let that one continue it's execution first. Is there some kind of timer in the background of the FX3 that the breakpoint might be messing up?

0 Likes
1 Solution
ThAl_4704151
Level 4
Level 4
25 sign-ins 25 replies posted 10 replies posted

After tinkering a bit, I found that if I set my breakpoints before I do anything with the GPIF-II state machine, I can break and continue without any trouble. It's not exactly what I was trying to do, but it's close enough for what I'm testing.

It seems kind of bizarre, but maybe there's some kind of timing constraint under the hood somewhere, and the breakpoints mess it up?

View solution in original post

0 Likes
3 Replies
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

Can you please provide more details on the below statement:

"I saw https://community.cypress.com/docs/DOC-18696, but trying the solution presented doesn't seem to have worked, and after watching the register mentioned there, it stays at the value I set it in the debug configuration, so it doesn't appear that the clock speed is changing as the aforementioned article describes"

- When was the register monitored?

- And what was the value observed?

"Something else I observed today was that if I start the program up again immediately after it hits the breakpoint, I can continue running the program. I only run into trouble if I take the time to switch to my other IDE and let that one continue it's execution first"

- I hope you are using resume button for continuing. Is that correct?

- Switching to other IDE means - switching from EZ-USB Suite to other IDE, doing some task and returning to EZ-USB Suite. Please confirm.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

The article I linked mentioned the PLL configuration register at 0xE0052000. I looked it up in the technical reference manual, did the arithmetic to confirm that the number specified in the article (0x00080014) seemed correct, and I tried it with the other number mentioned (0x00080015).

I set up a debugging expression in the expression tab of the debug view to read that memory location. The JTAG startup commands should have set it to 0x00080014 when I first started debugging, I saw that it was set to 0x00080014 when it hit the temporary breakpoint at the start of main, and when it hit the breakpoint that's currently giving me trouble, it was still set to 0x00080014.

I am using the resume button to continue. Just to confirm, it's the one with the yellow rectangle on the left and a green triangle on the right.

When I say switching to the other IDE, I mean I have them both running on Windows and connected to their respective microcontrollers. I just clicked the other one (Kiel Uv4) on the taskbar, told that one to resume (so that my 8051 would listen for the FX3 to set the GPIO_SEND_INTERRUPT pin, GPIO 27), clicked on eclipse in the taskbar, and then clicked resume. I get the error message after that.

I hope that's useful, and thank you for your help and patience.

Thomas

0 Likes
ThAl_4704151
Level 4
Level 4
25 sign-ins 25 replies posted 10 replies posted

After tinkering a bit, I found that if I set my breakpoints before I do anything with the GPIF-II state machine, I can break and continue without any trouble. It's not exactly what I was trying to do, but it's close enough for what I'm testing.

It seems kind of bizarre, but maybe there's some kind of timing constraint under the hood somewhere, and the breakpoints mess it up?

0 Likes