Has the FXCore chip on my Dev Board Died?

[PhilHaw]

My Dev Board has suddenly stopped working: no sound, no flashing LEDS with a program that has tap tempo so should be flashing etc.

Until yesterday I have been able to trial code by assembling and uploading via Notepad++ but today, without changing anything I am getting this error

............................................................................

+++++++++++++++++++

Error setting programming mode, check I2C address

Error in run from RAM mode

ERROR FAILED
Press any key to continue . . .

I'm running Windows 10 Professional on a PC. I can see the FT260 USB port in the "USB Device Manager" app but it seems to not be communicating with the FXCore on the I2C bus. I used my Salae Logic 8 probe to look at the I2C signals on the Dev Board SCL and SDA pins when I select the 'Run FXCore 0x30' menu item in Notepad++ and the FXCore is not acknowledging:

(Screenshot from Salae Logic 2): https://app.box.com/s/nktall4xazg1tyhthimciq0mhblbe1ni

I also scoped the SDO and SDI signals on the Dev Board and I see data going TO the FXCore on both SDI0 and SDI1 but no activity FROM the FXCore on the SDO pins.

Is my FXCore chip dead or is there something else I'm missing?

[Frank]

It is better to email me directly with a support question like this as I do not always check the forums but email always locates me

1. Check the I2C address, 99% of the time a switch was accidentally changed and is why the FXCore is not ACKing since the address doesn't match.

2. Is the chip working otherwise? Other programs in FLASH running fine?

3. Check USB devices, once in a while Windows gets stuck on a device and you have to delete it and let it find it again. If the board is not plugged in but there is a USB controller in Device Manager with the VID 0403 and PID 71D8 then it may be a stuck device.

4. When you say "I can see the FT260 USB port" do you still have the old FT260 dll installed? That has issues and why we moved to using native HID with the command line assembler. May be a conflict with the old dll and suggest you remove it if possible.

5. Try a different USB cable, I actually had one go bad last year.

It does seem to ACK the address but not the command to enter programming mode from what I see in the capture which usually means it is already in programming mode, did it work once then stop working? Possible it was left in programming mode and just need to be rest/power cycled?

FYI we are yet to have an FXCore die in the field, they are tough little things.

[PhilHaw]

Hi Frank and thanks for your suggestions. I've added some of my answers (ALL CAPS) to the questions below.

I'll remember to use your email for contact in future

*** As regards my mention of the FT260, that might be me getting confused and misquoting what I read! The Microsoft USB View app shows this device information and I can see the 'Interface Class Defined Device" so this is probably the native HID?

---===>Device Information<===---
English product name: "FXCore Dev Board"

ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address: 0x11
Open Pipes: 4

===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 = (64) Bytes
idVendor: 0x0403 = Future Technology Devices International Limited
idProduct: 0x71D8
bcdDevice: 0x2200
iManufacturer: 0x01
English (United States) "Experimental Noize"
iProduct: 0x02
English (United States) "FXCore Dev Board"
iSerialNumber: 0x00
bNumConfigurations: 0x01

It is better to email me directly with a support question like this as I do not always check the forums but email always locates me

1. Check the I2C address, 99% of the time a switch was accidentally changed and is why the FXCore is not ACKing since the address doesn't match. CHECKED AND DOUBLE-CHECKED!

2. Is the chip working otherwise? Other programs in FLASH running fine? NO. NONE OF THE PROGRAMS IN FLASH ARE WORKING. IN FACT SIGNAL IS NOT EVEN PASSED THROUGH WHEN THE ENABLE/_BYPASS_ PIN IS SET TO BYPASS

3. Check USB devices, once in a while Windows gets stuck on a device and you have to delete it and let it find it again. If the board is not plugged in but there is a USB controller in Device Manager with the VID 0403 and PID 71D8 then it may be a stuck device. THE USB DEVICE THAT APPEARS AND DISAPPEARS WHEN I PLUG IN OR REMOVE THE DEV BOARD SHOWS HARDWARE ID USB\VID_0403&PID_6030&REV_2200 and USB\VID_0403&PID_6030


4. When you say "I can see the FT260 USB port" do you still have the old FT260 dll installed? That has issues and why we moved to using native HID with the command line assembler. May be a conflict with the old dll and suggest you remove it if possible. NOT SURE ABOUT THIS (SEE ABOVE ***) BUT YESTERDAY THE DEV BOARD WAS PROGRAMMING OK BUT TODAY - ERROR!

5. Try a different USB cable, I actually had one go bad last year. NEITHER THE DEV BOARD NOR THE USB CABLE WAS MOVED BEFORE THE ERRANT BEHAVIOR STARTED

It does seem to ACK the address but not the command to enter programming mode from what I see in the capture which usually means it is already in programming mode, did it work once then stop working? Possible it was left in programming mode and just need to be rest/power cycled? YES I THOUGHT THAT WAS ODD. I HAVE RESET AND POWER CYCLED - STILL GIVES SAME I2C CAPTURE

FYI we are yet to have an FXCore die in the field, they are tough little things. THAT'S GOOD TO KNOW!

[Frank]

Hmmmm, very odd. I would next check all the pin voltages. Especially:

Reset

Oscillator clock

Master/slave

CODEC clocks and signals

Check all the jumpers are in the proper place, etc.

[PhilHaw]

The jumpers all seem to be in the correct places and of course I hadn't changed any but always worth checking nothing had moved.

The clock signals are all correct, which must mean the FXCore is powered up and at least the clock generation section is working:

Oscillator Clock: 12.288MHz
MCK (checked on R103): 8.192MHz
SCK: 2.048MHz
LRCK: 32kHz

As mentioned previously, I see data on both the SDI jumper pins but nothing on either SDO.

My eyesight is not great so probing the actual pins on the chip is not really possible as I am liable to short adjacent pins! When I touch the scope probe to the RST pin (just below the I2C address dip switches) I see +3.3V but I also hear the Windows sound that you get when you connect or disconnect a USB device. I wouldn't have thought a scope probe would have affected that node enough to trigger that?

[Frank]

The jumpers all seem to be in the correct places and of course I hadn't changed any but always worth checking nothing had moved.

The clock signals are all correct, which must mean the FXCore is powered up and at least the clock generation section is working:

Oscillator Clock: 12.288MHz
MCK (checked on R103): 8.192MHz
SCK: 2.048MHz
LRCK: 32kHz

Hmm, that all means the chip should be fully alive. The clock generation is complex due to the ability to select different sample rates and the master/slave selection.

My eyesight is not great so probing the actual pins on the chip is not really possible as I am liable to short adjacent pins! When I touch the scope probe to the RST pin (just below the I2C address dip switches) I see +3.3V but I also hear the Windows sound that you get when you connect or disconnect a USB device. I wouldn't have thought a scope probe would have affected that node enough to trigger that?

I tried and get the same thing, looking at the schematic the reset is also tied to the FT260 so I think that is what is causing the board to go on and off line with Windows.

I would try the following:

Run the assembler from the command line and just try a serial number read:
./FXCoreCmdAsm.exe -s

Try telling it to exit run from RAM mode (even though you should not be in it) from the command line:
./FXCoreCmdAsm.exe -ee
then try the serial number read

Then try to send a program, again from the command line like:
./FXCoreCmdAsm.exe -r mypro.fxc

Above assumes I2C address 0x30, add in the -i option if at a different address

Try a different USB port

Try running the board from an external supply, no connection to a computer and see if any of the 16 internal programs work.

I was about to release V2.4 of the assembler, just some upgrades to the equation solver as it could get confused between subtraction and negation of values depending on how a user wrote out an equation but will hold off a day or two so I can add in a little test routine and dump the entire status word.

[PhilHaw]

Thanks for the suggestions Frank.

So far, no joy

C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -s
Data was not acknowledged, please check hardware and restart

C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -ee
Opening stream to board

Returning to run mode FXCore at 0X30

Sending return to run mode command to the dev board, 0X5AA5

Slave address was not acknowledged, please check hardware and restart

C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -s
Slave address was not acknowledged, please check hardware and restart

C:\Program Files (x86)\Experimental Noize\FXCore Assembler>

I didn't bother to try sending a program as it looks like the FXCore is not in the mood to talk!

I did try another USB cable and another USB port but still no luck.

UPDATE No programs run and no sound feeds through even in bypass when I ran it with the external power supply.

[Frank]

New assembler V2.4.0.0 posted for Windows, Mac versions will follow in a few days.

2 new options, "-stat" and "-statno"

-stat will attempt to open the chip and return the status word and break it down, it will also return FT260 status info so we can try to see if the USB/I2C interface is causing any issue

-statno is basically the same but assumes the chip is already in programming mode.

Plug in the board and try the assembler with -stat

Unplug and replug in board and try -statno

Unplug and replug in board and try -stat followed by -statno

Also please get someone that can help you read the pins so we can see the levels. While I am beginning to think the chip may be the issue I want to eliminate any external components causing any problems. Also please check the regulators, probably fine but want to eliminate them as a possibility.

[PhilHaw]

Frank thanks so much for the new Assembler. I followed your instructions and the results I got are as below.

I don't have anyone nearby with the necessary eyesight and skills. Our team is located in different countries!

Mick has suggested I try reflowing the solder joints on the FXCore chip in case there's a suspect joint. I might be able to manage that with plenty of flux, good light and my desktop magnifier!!!

--------------------------------------------------------------------------------------------------------------------------
C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -stat
Opened board and received handle

Sent command and got status FT260_OK

Waiting on I2C bus

I2C status: 0x2E
Slave address was not acknowledged, please check hardware and restart
Data was not acknowledged, please check hardware and restart
I2C controller idle
Closing board and got status FT260_OK

----------------------------------------------------------------------------------------------------------------------------
C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -statno
Opened board and received handle

Waiting on I2C bus

I2C status: 0x00
Board opened waiting on FXCore to enter programming mode


Unhandled Exception: System.TimeoutException: Operation timed out.
at HidSharp.Platform.Windows.NativeMethods.OverlappedOperation(IntPtr ioHandle, IntPtr eventHandle, Int32 eventTimeout, IntPtr closeEventHandle, Boolean overlapResult, NativeOverlapped* overlapped, UInt32& bytesTransferred)
at HidSharp.Platform.Windows.WinHidStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at HidSharp.HidStream.Read(Byte[] buffer)
at FXCoreAsm.FT260_wrap.FT260_HID_I2C_Read(HidStream devstream, Byte i2caddr, FT260_I2C_FLAG flag, Byte[]& data, UInt32 bytestoread, UInt32& bytes_read, UInt32 timeout)
at FXCoreCmdAsm.Program.GetChipStatus(Byte fxc_addr, Boolean do_open)
at FXCoreCmdAsm.Program.Main(String[] args)

----------------------------------------------------------------------------------------------------------------------------------
C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -stat
Opened board and received handle

Sent command and got status FT260_OK

Waiting on I2C bus

I2C status: 0x2A
Data was not acknowledged, please check hardware and restart
I2C controller idle
Closing board and got status FT260_OK

C:\Program Files (x86)\Experimental Noize\FXCore Assembler>FXCoreCmdAsm.exe -statno
Opened board and received handle

Waiting on I2C bus

I2C status: 0x00
Board opened waiting on FXCore to enter programming mode

I2C status FT260_OK
Returned data:
0xFFFFFFFFFFFFFFFFFFFFFF

Program successfully received
At least 1 register presets successfully received
MREGs register presets successfully received
SFRs register presets successfully received
CREGs register presets successfully received
Unknown command
Command length correct
Parameter in range
Command allowed in current state
Calculated checksum and received checksum matched
No unknown program transfer errors
No FLASH erase error
No FLASH write error
Command high byte 0xFF
Command low byte 0xFF
Program slots status 0xFFFF
Production version ID 0xFFFF
Serial number 0xFFFFFFFF
Exiting programming mode

Got status FT260_OK
Closing board

Closing board got status FT260_OK

[Frank]

So it looks like the FT260 is OK and PC<->FT260 comms is OK so it is either a board issue or a bad FXCore. I'm leaning towards a bad FXCore or maybe a bad solder joint as Mick suggests since we appear to be getting partial replies. I would also reflow the FT260 in case it is FT260 data or clock that has a bad joint. But it would not surprise me at this point if it is the FXCore, first field failure after all the thousands we have shipped.

Too bad no one local that can help check the pins. You might also reflow the I2C pull-up resistors on the board, I doubt they are an issue since we see the I2C lines pull high but as long as you are touching up points it can't hurt.

If you have a hot air station you might try replacing the FXCore on the board but your eyes may not be up to it from the sound of it. My eyes are also not great so I use magnifiers to work on the boards.

Avoid water soluble flux, that stuff is conductive and corrosive. Clean the board well after, sometimes dirt causes issues.