Yes, if you are still working with the PCBA that had the +1v0 rail spike to ~+2v9 on the CPU then there is no hope for that XMOS CPU. Take it to the back shed and shoot / bury it as Mr. Wonderful would say on Shark Tank. That CPU did not have a chance, hoping it was not too painful for the fella.
Replace with a fresh CPU or test with a fresh PCBA and repeat your testing. With some luck, you may be ok if the voltage rails are stable. However, the proper power sequencing is necessary so the end user is able to use this widget upon each and every power up cycle.
When you respin the design, please post the schematic before generating your PCB layout for a review.
XVF-3510 development and USB device
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
-
- Member++
- Posts: 26
- Joined: Fri May 22, 2020 5:52 pm
I was able to get the IC to start! Thanks so much.
I had started with a fresh board and soldered the QFN until there were no shorts and it looks like everything is connected. I still have to short the pin on U12 to ground to get the device to show up, after bootup.
However, when I try to flash the XMOS chip with the xTAG, I get this error:
I found this post and am going through the steps. I think the issue is #2, the RST_N Pin is being held high.
I checked the 25Mhz clock, and it is giving a good signal. I checked the output of the mic clock, and nothing is showing up. My 1v and 3.3v both measure good.
I still have work to do, but I'm making progress. Thanks for your help.
Code: Select all
bash-3.2$ xflash --list-devices
Available XMOS Devices
----------------------
ID Name Adapter ID Devices
-- ---- ---------- -------
0 XMOS XTAG-3 2KbYj_za O[0]
However, when I try to flash the XMOS chip with the xTAG, I get this error:
Code: Select all
bash-3.2$ xflash --id 0 "XM-013830-SM-F-XVF3510 Adaptive USB Firmware binary.xe"
xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz
xrun: Cannot load image, XCore 0 is not enabled
Error: F03013 Failed to run : 0x7ffeefbeb6a0.
Would you suggest removing the BAT54 (D20 on my schematics) or something else?1. The JTAG interface to the XCore has been disabled in the OTP security
register.
2. The device is being permanently held in reset by the RST_N signal.
3. No clock is being supplied to the device; or the clock frequency
supplied to the device is unsuitable for the selected PLL multiplier. The
PLL multiplier is set using the MODE pins and should be configured so that
the XCore boots up at or below its maximum frequency. Further details on
the MODE pins can be found in the relevant device datasheet.
4. The VDD Core supply is outside of tolerance (see the device datasheet).
5. The VDD PLL supply is outside of tolerance (see the device datasheet) or
not present, or has a filter with too high a resistor. This will mean that
the PLL is not locked and hence the XCore will be kept in reset.
6. The power supplies have not been correctly sequenced. The VDDIO (and
OTP_VDDIO if present) supply must be within specification (3.0V-3.6V)
before the VDD Core supply is turned on; see the datasheet for details.
7. The device, especially the ground paddle, has not been correctly
soldered to the board. This can either be in the form of not connected
solder joints or shorted solder joints to other pins, ground or power.
I checked the 25Mhz clock, and it is giving a good signal. I checked the output of the mic clock, and nothing is showing up. My 1v and 3.3v both measure good.
I still have work to do, but I'm making progress. Thanks for your help.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Very good to hear. You are making progress indeed!
Suggest you replicate as close as possible the XMOS reference designs as they are proven to work. For this reason, you should apply another open drain buffer on your design between the XTAG3 IDC header pin and the #RESET of the CPU. This way, the OD output of U12 OR the XTAG3 tool can drive the #RESET pin low and will tri-state otherwise to get out of the way. This is perfectly legal in the digital world to share outputs as long as each driver can tri-state / are open drain style. The pull-up resistor performs the soft logic high.
On the xflash tool error - expand the log by placing:
in the command line and share the output.
Aside from the xflash use, can you upload a small chunk of code to perhaps toggle a GPIO pin? Such as a simple LED blinky? Does this custom piece of code upload and run on your working PCBA? Recommend to start with this.
The next code to test would be the XMOS USB MOUSE HID example -> very simple code that should run on your custom PCBA as-is and act like a mouse that moves in a square pattern on your Windows box. Allow this to run for a while which validates that USB 2.0 High Speed (480mbps) data rate traffic is stable on your PCB layout.
Once you can verify that a simple LED blinky is working & the USB 2.0 MOUSE IP works, then you are almost done (aside from your custom audio IP verification).
One additional comment worth noting is that this CPU is currently configured for QSPI (Quad SPI) mode of interfacing. The firmware will be stored inside your QSPI capable flash device. All good so far except can you confirm if the FACTORY default setting for your flash memory device is QSPI enabled or SPI enabled? Suspecting it is SPI enabled and this can be deal breaker. From my fading memory, if XMOS has the support for this specific flash device (IDs, registers all match) or you have extended the QSPI flash table manually, then you should be ok and the XFLASH tool will do this QSPI enabling for you. There is a register inside the flash that is required to be set to "1" so that the SPI mode converts to QSPI mode. Otherwise, you are working with 2 very different styles of hand shakes. Once this QSPI mode is enabled, then you can proceed to upload / download your firmware to this QSPI enabled flash device. Upon a fresh power up, the XMOS CPU will demand to load from a QSPI enabled flash device.
Start with fixing the XTAG3 external open drain issue - personally prefer the 74HC07 (SN74LVC07A) method but in a pinch you could try just a simple mosfet with the GATE being driven by the XTAG3_RESET pin. Remove the diodes (BAT54A) from the design.
If you are in the USA, I think you can sneak out the 74HC07 or similar open drain buffer out of Arrow today for possibly receiving tomorrow to continue your testing.
Very exciting to know that you are getting closer!!
Suggest you replicate as close as possible the XMOS reference designs as they are proven to work. For this reason, you should apply another open drain buffer on your design between the XTAG3 IDC header pin and the #RESET of the CPU. This way, the OD output of U12 OR the XTAG3 tool can drive the #RESET pin low and will tri-state otherwise to get out of the way. This is perfectly legal in the digital world to share outputs as long as each driver can tri-state / are open drain style. The pull-up resistor performs the soft logic high.
On the xflash tool error - expand the log by placing:
Code: Select all
--verbose
Aside from the xflash use, can you upload a small chunk of code to perhaps toggle a GPIO pin? Such as a simple LED blinky? Does this custom piece of code upload and run on your working PCBA? Recommend to start with this.
The next code to test would be the XMOS USB MOUSE HID example -> very simple code that should run on your custom PCBA as-is and act like a mouse that moves in a square pattern on your Windows box. Allow this to run for a while which validates that USB 2.0 High Speed (480mbps) data rate traffic is stable on your PCB layout.
Once you can verify that a simple LED blinky is working & the USB 2.0 MOUSE IP works, then you are almost done (aside from your custom audio IP verification).
One additional comment worth noting is that this CPU is currently configured for QSPI (Quad SPI) mode of interfacing. The firmware will be stored inside your QSPI capable flash device. All good so far except can you confirm if the FACTORY default setting for your flash memory device is QSPI enabled or SPI enabled? Suspecting it is SPI enabled and this can be deal breaker. From my fading memory, if XMOS has the support for this specific flash device (IDs, registers all match) or you have extended the QSPI flash table manually, then you should be ok and the XFLASH tool will do this QSPI enabling for you. There is a register inside the flash that is required to be set to "1" so that the SPI mode converts to QSPI mode. Otherwise, you are working with 2 very different styles of hand shakes. Once this QSPI mode is enabled, then you can proceed to upload / download your firmware to this QSPI enabled flash device. Upon a fresh power up, the XMOS CPU will demand to load from a QSPI enabled flash device.
Start with fixing the XTAG3 external open drain issue - personally prefer the 74HC07 (SN74LVC07A) method but in a pinch you could try just a simple mosfet with the GATE being driven by the XTAG3_RESET pin. Remove the diodes (BAT54A) from the design.
If you are in the USA, I think you can sneak out the 74HC07 or similar open drain buffer out of Arrow today for possibly receiving tomorrow to continue your testing.
Very exciting to know that you are getting closer!!
-
- Member++
- Posts: 26
- Joined: Fri May 22, 2020 5:52 pm
On the xflash tool error - expand the log by placing:
Code: Select all
--verbose
in the command line and share the output.
Code: Select all
bash-3.2$ xflash --id 0 "XM-013830-SM-F-XVF3510 Adaptive USB Firmware binary.xe" --verbose
XFlash_Application found _start :40000 on Node 0
XFlash_Application found _DoSyscall :4e9f0 on Node 0
XFlash_Application found _DoException :400a4 on Node 0
XFlash_Application found _start :40000 on Node 0
XFlash_Application found _DoSyscall :4e214 on Node 0
XFlash_Application found _DoException :400a4 on Node 0
XFlash_Application : Attempting to Compress Binary Data
libcompressor marker 1=181
libcompressor marker 2=165
libcompressor marker 3=91
libcompressor best marker length 3 2 2
libcompressor best marker length 3 2 3
libcompressor best marker length 3 2 4
libcompressor best marker length 3 2 5
libcompressor best marker length 3 2 6
libcompressor DoCompression_Compress took : 1905ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-ae754b73" -x xn "target-xn-v0-f992737a" -o decompressor-9dc82ba4
libcompressor validating decompressor decompressor-9dc82ba4
libcompressor launching simulator decompressor-9dc82ba4 --disable-syscalls --max-cycles 100000000
libcompressor simulator starting @0x40000
libcompressor simulator terminate @0x7ff58
libcompressor decompressor validated
XFlash_Application on Node : 0 compressed from : 76928 bytes to : 47532 bytes (38.21%)
libcompressor marker 1=107
libcompressor marker 2=181
libcompressor marker 3=219
libcompressor best marker length 3 2 2
libcompressor best marker length 3 2 3
libcompressor DoCompression_Compress took : 3904ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-a3503468" -x xn "target-xn-v0-f992737a" -o decompressor-b59530d4
libcompressor validating decompressor decompressor-b59530d4
libcompressor launching simulator decompressor-b59530d4 --disable-syscalls --max-cycles 100000000
libcompressor simulator starting @0x40000
libcompressor simulator terminate @0x7ff58
libcompressor decompressor validated
XFlash_Application on Node : 0 compressed from : 82972 bytes to : 62636 bytes (24.51%)
XFlash::DoXFlash
XFlash::DoImageProgramming
XFlash::GetDeviceInfo
XFlash_DeviceInfo::GetDeviceInfo_SQI
XFlash::BuildFlashBinaryFile
XFlash_Builder_S2L::BuildStage2Loaders Factory
xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz
Stage2_Loader::Compile : xcc -Wno-bidirectional-buffered-port -Xmapper --dontenablesodlinks -Xmapper --nochaninit -Xmapper --noinitialtidy -Xmapper --image-base -Xmapper 0x40080 -Xmapper --image-size -Xmapper 0x3ff80 -Xmapper --wno110 -Xmapper --wno226 -Xmapper --wnoXN -std=c99 -O2 -x xn "target-xn-v0-f992737a" -x xc s2l-n0-98053661 -lstage2loader -lswitchsetup -lsqiaccess -lquadspi -llocks -o s2l-n0-1194ff7b
Stage2Loader found _DoSyscall : 0x404c8 on Node 0
Stage2Loader found _DoException : 0x40124 on Node 0
Stage2_Loader : Attempting to Compress Binary Data
libcompressor marker 1=77
libcompressor marker 2=125
libcompressor marker 3=181
libcompressor best marker length 3 2 2
libcompressor best marker length 3 2 3
libcompressor best marker length 3 2 4
libcompressor best marker length 3 2 5
libcompressor best marker length 4 2 5
libcompressor DoCompression_Compress took : 94ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-14ad97a3" -x xn "target-xn-v0-f992737a" -o decompressor-ecf7fe5a
libcompressor validating decompressor decompressor-ecf7fe5a
libcompressor launching simulator decompressor-ecf7fe5a --disable-syscalls --max-cycles 100000000
libcompressor simulator starting @0x40000
libcompressor simulator terminate @0x7feda
libcompressor decompressor validated
Stage2_Loader on Node : 0 compressed from : 5536 bytes to : 4248 bytes (23.27%)
Stage2_SwitchSetup::Compile : xcc -c -march=xs2a -x assembler-with-cpp swstup-n0v0-c966cf2f -o swstup-n0v0-aeccb609
Stage2_SwitchSetup::Compile : xcc -nostartfiles -Wno-bidirectional-buffered-port -Xmapper --first -Xmapper swstup-n0v0-aeccb609 -Xmapper --dontenablesodlinks -Xmapper --nochaninit -Xmapper --noinitialtidy -Xmapper --wno110 -Xmapper --wno226 -Xmapper --wnoXN -std=c99 -O2 -x xn "target-xn-v0-f992737a" -x xc swstup-n0v0-f8f45a7f -lswitchsetup -o swstup-n0v0-e19bc7bf
XFlash_Builder_Image::BuildImages Factory
XFlash_Builder_Image::BuildImageTable
master node = 0
node = 0
XFlash_Builder_Image::BuildImageTable num cores for image table = 2
XFlash_Builder_Image::CalculateBufferSize Starting calculation _total_image_size=0
XFlash_Builder_Image::CalculateBufferSize Add Image Header _total_image_size=34
XFlash_Builder_Image::CalculateBufferSize Add Switch Setup header _total_image_size=3c
XFlash_Builder_Image::CalculateBufferSize Add Per Core header _total_image_size=54
XFlash_Builder_Image::CalculateBufferSize_SwitchSetup _total_image_size=7ac
XFlash_Builder_Image::CalculateBufferSize_Application application size = b9b0 _total_image_size = c15c
XFlash_Builder_Image::CalculateBufferSize_Application application size = f4b0 _total_image_size = 1b60c
XFlash_Builder_Image::BuildImageTable allocated image buffer size = 1b60c
XFlash_Builder_Image::WriteBuffer_ImageHeader
XFlash_Builder_Image::WriteBuffer_SwitchSetup current switch setup table offset : 34
XFlash_Builder_Image::WriteBuffer_SwitchSetup current application data offset : 54
XFlash_Builder_Image::WriteBuffer_SwitchSetup size : 754
XFlash_Builder_Image::WriteBuffer_SwitchSetup aligned_size : 758
XFlash_Builder_Image::WriteBuffer_SwitchSetup init_vec_shift : 0
XFlash_Builder_Image::WriteBuffer_Application
XFlash_Builder_Image::WriteBuffer_Application for node : 0
XFlash_Builder_Image::WriteBuffer_Application for core : 0
XFlash_Builder_Image::WriteBuffer_Application current core table offset : 3c
XFlash_Builder_Image::WriteBuffer_Application current application data offset : 7ac
XFlash_Builder_Image::WriteBuffer_Application size : b9ac
XFlash_Builder_Image::WriteBuffer_Application aligned_size : b9b0
XFlash_Builder_Image::WriteBuffer_Application init_vec_shift : 0
XFlash_Builder_Image::WriteBuffer_Application chan end : 80020002
XFlash_Builder_Image::WriteBuffer_Application for core : 1
XFlash_Builder_Image::WriteBuffer_Application current core table offset : 48
XFlash_Builder_Image::WriteBuffer_Application current application data offset : c15c
XFlash_Builder_Image::WriteBuffer_Application size : f4ac
XFlash_Builder_Image::WriteBuffer_Application aligned_size : f4b0
XFlash_Builder_Image::WriteBuffer_Application init_vec_shift : 0
XFlash_Builder_Image::WriteBuffer_Application chan end : 80030002
XFlash_Builder_Image::WriteBuffer_CRC
XFlash_Builder_Binary::BuildBinary
XFlash_Builder_Binary::CalculateBufferSize_Factory
XFlash_Builder_Binary::CalculateBufferSize_Factory : Adding s2l size word (4)4
XFlash_Builder_Binary::CalculateBufferSize_Factory : Adding s2l app (1118) 111c
XFlash_Builder_Binary::CalculateBufferSize_Factory : Adding s2l crc (4)1120
XFlash_Builder_Binary::CalculateBufferSize_Factory : Adding factory app (1b60c) 1c72c
XFlash_Builder_Binary::CalculateBufferSize_Factory : Adding sector padding (8d4) 1d000
XFlash_Builder_Binary::CalculateBufferSize_Factory : First User Sector offset = 1d000
XFlash_Builder_Binary::GetSearchLimitPadding : current size (1d000) 0
XFlash_Builder_Binary::CalculateBufferSize_Data
XFlash_Builder_Binary::BuildBinary : Allocating buffer - 1d000
XFlash_Builder_Binary::GetSearchLimitPadding : current size (1d000) 0
XFlash_Builder_Binary::WriteBufferToBinary : flash_bin_node0
XFlash_Programmer_Program::DoProgram
XFlash_Programmer_Program::GenerateSource
XFlash_Programmer_Program::IssueCompileCommand :xcc -w -Xmapper --dontenablesodlinks -O2 -lquadspi -x xc "fp-bdb10162" -x xn "target-xn-v0-f992737a" -D VERBOSE=1 -D MONITOR=1 -D ERASE_ALL_FIRST=1 -o "fp-412beb97"
XFlash_Utils::BuildRunCommand : xrun --io --id 0 fp-412beb97
xrun: Cannot load image, XCore 0 is not enabled
Error: F03013 Failed to run : 0x7ffee0de1690.
-
- Member++
- Posts: 26
- Joined: Fri May 22, 2020 5:52 pm
I haven't coded anything on the xTimeComposer yet. Do you have some sample code or a good guide to get me started with that? I'm just sending pre-compiled binaries right now.mon2 wrote: ↑Thu Aug 13, 2020 7:12 pm
Aside from the xflash use, can you upload a small chunk of code to perhaps toggle a GPIO pin? Such as a simple LED blinky? Does this custom piece of code upload and run on your working PCBA? Recommend to start with this.
The next code to test would be the XMOS USB MOUSE HID example -> very simple code that should run on your custom PCBA as-is and act like a mouse that moves in a square pattern on your Windows box. Allow this to run for a while which validates that USB 2.0 High Speed (480mbps) data rate traffic is stable on your PCB layout.
Once you can verify that a simple LED blinky is working & the USB 2.0 MOUSE IP works, then you are almost done (aside from your custom audio IP verification).
I'm going to research how to do this. This is the Flash chip I'm using AT25SF161-SHD-TOne additional comment worth noting is that this CPU is currently configured for QSPI (Quad SPI) mode of interfacing. The firmware will be stored inside your QSPI capable flash device. All good so far except can you confirm if the FACTORY default setting for your flash memory device is QSPI enabled or SPI enabled? Suspecting it is SPI enabled and this can be deal breaker. From my fading memory, if XMOS has the support for this specific flash device (IDs, registers all match) or you have extended the QSPI flash table manually, then you should be ok and the XFLASH tool will do this QSPI enabling for you. There is a register inside the flash that is required to be set to "1" so that the SPI mode converts to QSPI mode. Otherwise, you are working with 2 very different styles of hand shakes. Once this QSPI mode is enabled, then you can proceed to upload / download your firmware to this QSPI enabled flash device. Upon a fresh power up, the XMOS CPU will demand to load from a QSPI enabled flash device.
16-Mbit, 2.5V Minimum - SPI Serial Flash Memory with Dual-I/O and Quad-IO Support
Yup, I'm in the USA, Los Angeles. I might even have that chip at my local shop.Start with fixing the XTAG3 external open drain issue - personally prefer the 74HC07 (SN74LVC07A) method but in a pinch you could try just a simple mosfet with the GATE being driven by the XTAG3_RESET pin. Remove the diodes (BAT54A) from the design.
If you are in the USA, I think you can sneak out the 74HC07 or similar open drain buffer out of Arrow today for possibly receiving tomorrow to continue your testing.
Yeah! I feel good about this! Thanks for your help!Very exciting to know that you are getting closer!!
Edit: Attached is the base board schematics for the dev board. I checked, the flash chip I'm using is the same one on the XMOS dev board.
You do not have the required permissions to view the files attached to this post.
Last edited by Kevin Jordan on Thu Aug 13, 2020 8:02 pm, edited 1 time in total.
-
- Member++
- Posts: 26
- Joined: Fri May 22, 2020 5:52 pm
Also, back to your example code to upload... As far as I know, the XVF-3510 doesn't have an xCORE inside to run custom code. It would be great if I was wrong about that, but I didn't think it did, according to the datasheet. I just double-checked and found no reference to xCORE in the datasheet.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. Thanks for the ref design schematic - very helpful.
1) since XMOS features the same diode on the XTAG3, in theory it should work. If the same setup is working with the XMOS ref design then so should your version of the custom design. As a rule, just prefer to use real logic gates for such tasks.
2) For sure the CPU is XCORE-200 based with custom internal mods for voice processing but you are correct, it is a canned solution and do not see this CPU listed inside the toolchain from XMOS. That is a mixed blessing. In theory, great that you can just apply their proven firmware onto your PCB but not so great to test with simple custom code.
3) Great choice on the target QSPI flash - you are using what they have proven already to be compatible. However, it is quite possible that they have enabled the QSPI bit at the factory (Atmel / Microchip) or @ XMOS and then applied the firmware. That is, your blank may be with the QSPI bit = "0" so you are stuck in SPI mode.
4) However, suspecting that this is not the show stopper at this time. When you power up, do you see activity on the QSPI CLK pin? The XMOS CPU is the SPI bus master so it will drive the CLK pin to clock out data from the external QSPI flash device. Check for this.
5) If you feel up to it, consider to flash known good firmware on your XMOS kit -> carefully desolder this QSPI flash off the XMOS kit and transplant onto your custom PCBA. Does this process allow for your custom PCBA to work?
6) One concern that is still active is that you noted that had to manually pulse the #RESET line. That almost indicates that the power sequencing may be a factor. Again, best to follow the preachers @ XMOS as they have gone through all of these stumbling blocks already. Clone what works for them.
If the XMOS QSPI flash allows for your custom PCB to work -> then take your fresh Atmel FLASH and apply onto your XMOS kit. Do you follow the same xflash command line procedure on the XMOS kit and the flash is able to be programmed with the passed .xe firmware?
So to rephrase, you can xflash your external flash memory device with the same command line values & XMOS KIT -> the tool does not complain? Then you can power cycle the XMOS kit and it simply works for you? If yes, there is still something kooky with your custom PCBA. The quick check will be to take the programmed flash from XMOS kit and apply on your PCB and test the power up operating mode.
7) In comparing to the XMOS ref design, can you clone the resistor values for the 1v0 rail? The values are not the same on your custom PCB. Perhaps the ratios are close enough but again, verify that the 1v0 rail is spot on stable.
My bad...thought the AT flash prefix = Atmel / Microchip but is not. Either way, if you are using the same p/n as XMOS, you will be in good company :)
1) since XMOS features the same diode on the XTAG3, in theory it should work. If the same setup is working with the XMOS ref design then so should your version of the custom design. As a rule, just prefer to use real logic gates for such tasks.
2) For sure the CPU is XCORE-200 based with custom internal mods for voice processing but you are correct, it is a canned solution and do not see this CPU listed inside the toolchain from XMOS. That is a mixed blessing. In theory, great that you can just apply their proven firmware onto your PCB but not so great to test with simple custom code.
3) Great choice on the target QSPI flash - you are using what they have proven already to be compatible. However, it is quite possible that they have enabled the QSPI bit at the factory (Atmel / Microchip) or @ XMOS and then applied the firmware. That is, your blank may be with the QSPI bit = "0" so you are stuck in SPI mode.
4) However, suspecting that this is not the show stopper at this time. When you power up, do you see activity on the QSPI CLK pin? The XMOS CPU is the SPI bus master so it will drive the CLK pin to clock out data from the external QSPI flash device. Check for this.
5) If you feel up to it, consider to flash known good firmware on your XMOS kit -> carefully desolder this QSPI flash off the XMOS kit and transplant onto your custom PCBA. Does this process allow for your custom PCBA to work?
6) One concern that is still active is that you noted that had to manually pulse the #RESET line. That almost indicates that the power sequencing may be a factor. Again, best to follow the preachers @ XMOS as they have gone through all of these stumbling blocks already. Clone what works for them.
If the XMOS QSPI flash allows for your custom PCB to work -> then take your fresh Atmel FLASH and apply onto your XMOS kit. Do you follow the same xflash command line procedure on the XMOS kit and the flash is able to be programmed with the passed .xe firmware?
So to rephrase, you can xflash your external flash memory device with the same command line values & XMOS KIT -> the tool does not complain? Then you can power cycle the XMOS kit and it simply works for you? If yes, there is still something kooky with your custom PCBA. The quick check will be to take the programmed flash from XMOS kit and apply on your PCB and test the power up operating mode.
7) In comparing to the XMOS ref design, can you clone the resistor values for the 1v0 rail? The values are not the same on your custom PCB. Perhaps the ratios are close enough but again, verify that the 1v0 rail is spot on stable.
My bad...thought the AT flash prefix = Atmel / Microchip but is not. Either way, if you are using the same p/n as XMOS, you will be in good company :)
You do not have the required permissions to view the files attached to this post.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Found an important and missing resistor for the BOOT_SEL of the CPU. The XMOS ref design features a BOOT_SEL resistor on the QSPI_D1 pin. This pin will be read upon a power up cycle and determines if the CPU is the QSPI Bus master or Bus slave (ie. external CPU will then clock in the firmware). You want this BOOT_SEL = 0 configuration.
This strapping resistor is missing from the current schematic.
After the sampling of this BOOT_SEL definition pin, the same pin is used by the QSPI flash interface to load in the firmware from the outside world.
This strapping resistor is missing from the current schematic.
After the sampling of this BOOT_SEL definition pin, the same pin is used by the QSPI flash interface to load in the firmware from the outside world.
You do not have the required permissions to view the files attached to this post.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. Please follow the procedure shown in page 19 of the attached document to reflash the firmware onto your XMOS kit / custom PCB. Does this improve the programming of the firmware?
There are other juicy tidbits inside this document on flash programming that are worth a review.
Correcting my earlier comment about the use of the pull-up resistors on the QSPI_CS and the SPI_CS pins. These are 2 different pins and serve a different purpose. So stick with the XMOS ref design.
That is, the QSPI pins are for booting the firmware from the external QSPI flash memory device. This demands the use of the local pull-up on the QSPI_CS pin # 1 of the flash device.
If you should decide to boot from an external SPI bus master (ie. like the kit shows), then a different set of pins will boot using the SPI interface protocol. This demands the use of the local pull-up on the SPI_CS pin 15 of the XMOS CPU.
The decision on which group of pins will be used is configured through the BOOT_SEL resistor as noted in the earlier post. You want BOOT_SEL=0 on this 4k7 resistor.
It is odd that the XMOS datasheet for this and every other CPU datasheet clearly notes the requirement for power sequencing yet this is not followed in this reference design. Still recommend that you do design with the proper sequencing of the rails else you will face power up latching issues.
There are other juicy tidbits inside this document on flash programming that are worth a review.
Correcting my earlier comment about the use of the pull-up resistors on the QSPI_CS and the SPI_CS pins. These are 2 different pins and serve a different purpose. So stick with the XMOS ref design.
That is, the QSPI pins are for booting the firmware from the external QSPI flash memory device. This demands the use of the local pull-up on the QSPI_CS pin # 1 of the flash device.
If you should decide to boot from an external SPI bus master (ie. like the kit shows), then a different set of pins will boot using the SPI interface protocol. This demands the use of the local pull-up on the SPI_CS pin 15 of the XMOS CPU.
The decision on which group of pins will be used is configured through the BOOT_SEL resistor as noted in the earlier post. You want BOOT_SEL=0 on this 4k7 resistor.
It is odd that the XMOS datasheet for this and every other CPU datasheet clearly notes the requirement for power sequencing yet this is not followed in this reference design. Still recommend that you do design with the proper sequencing of the rails else you will face power up latching issues.
You do not have the required permissions to view the files attached to this post.
-
- Member++
- Posts: 26
- Joined: Fri May 22, 2020 5:52 pm
1) Ok1) since XMOS features the same diode on the XTAG3, in theory it should work. If the same setup is working with the XMOS ref design then so should your version of the custom design. As a rule, just prefer to use real logic gates for such tasks.
2) For sure the CPU is XCORE-200 based with custom internal mods for voice processing but you are correct, it is a canned solution and do not see this CPU listed inside the toolchain from XMOS. That is a mixed blessing. In theory, great that you can just apply their proven firmware onto your PCB but not so great to test with simple custom code.
2) We understood going in that it is a canned chip, and somewhat kneecapped, but that's ok. We don't have the resources right now for custom firmware, so the chip with just the audio recording and AEC is all we really need.
Thanks. I tried to keep as many parts the same as the reference design.3) Great choice on the target QSPI flash - you are using what they have proven already to be compatible. However, it is quite possible that they have enabled the QSPI bit at the factory (Atmel / Microchip) or @ XMOS and then applied the firmware. That is, your blank may be with the QSPI bit = "0" so you are stuck in SPI mode.
I see voltage on the CLK pin, but no pulse. I see 3.6v with my Fluke, and 460mV on my Rigol Scope, which is odd. I have a blue wire onto the CLK pin on the Flash chip, and double checked those numbers.4) However, suspecting that this is not the show stopper at this time. When you power up, do you see activity on the QSPI CLK pin? The XMOS CPU is the SPI bus master so it will drive the CLK pin to clock out data from the external QSPI flash device. Check for this.
This seems like a bad idea, at least for me. My QFN skills are not that great, and the only working board I have is the XMOS DevKit. I have an updated layout, with 0.5mm longer pins on each QFN, so I can more easily hand solder these into place. I can have new boards printed, mostly assembled and in my hands in a week.5) If you feel up to it, consider to flash known good firmware on your XMOS kit -> carefully desolder this QSPI flash off the XMOS kit and transplant onto your custom PCBA. Does this process allow for your custom PCBA to work?
I looked again, and I copied their power sequence as far as I could tell.6) One concern that is still active is that you noted that had to manually pulse the #RESET line. That almost indicates that the power sequencing may be a factor. Again, best to follow the preachers @ XMOS as they have gone through all of these stumbling blocks already. Clone what works for them.
I'm doing the exact same procedure to flash the Devkit as my custom PCB and it works flashing the DevKit. I just tried it again, and it was successful.If the XMOS QSPI flash allows for your custom PCB to work -> then take your fresh Atmel FLASH and apply onto your XMOS kit. Do you follow the same xflash command line procedure on the XMOS kit and the flash is able to be programmed with the passed .xe firmware?
So to rephrase, you can xflash your external flash memory device with the same command line values & XMOS KIT -> the tool does not complain? Then you can power cycle the XMOS kit and it simply works for you? If yes, there is still something kooky with your custom PCBA. The quick check will be to take the programmed flash from XMOS kit and apply on your PCB and test the power up operating mode.
Code: Select all
bash-3.2$ xflash --id 0 "XM-013830-SM-F-XVF3510 Adaptive USB Firmware binary.xe"
xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz
Site 0 has finished successfully.
bash-3.2$
My 1v rail is very stable at 1.0v (measures 1.004v on Fluke). In the datasheet for the XVF-3510, they call for 1.5amps on the 1v0 rail. The buck they use on the DevKit only provides 1.0amps. The buck I chose MP2359DJ-LF-Z provides 1.2amps, is cheaper, and JLCPCB considers it one of their basic parts.7) In comparing to the XMOS ref design, can you clone the resistor values for the 1v0 rail? The values are not the same on your custom PCB. Perhaps the ratios are close enough but again, verify that the 1v0 rail is spot on stable.