Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Cyclone for ARM / Kinetis KM14Z128 / MXIC MX25L8006 woes
Jon G. Aug 7, 2015 at 12:25 PM (12:25 hours)
Staff: Gerardo R.

  • I'm using:
    * Cyclone for ARM Devices 1.61-0.7

    On a custom board with:
    * Kinetis MKM14Z128CHH5
    * MXIC MX25L8006EM1I attached to G2-G5 (/CS,SCLK,MOSI,MISO respectively).

    I've all these lines taken out to a logic analyser.

    I can program the KM14's internal ROM successfully. Using our own ROM image, in which we talk to the SFLASH, I see valid movement on all SPI lines on the analyser, so the wiring to the LA is correct and undamaged.

    To program the MXIC flash through the Cyclone, I'm using a modified version of the MXIC_MX25L8006E_8x1Meg_sw_spi.arp file from the current download.

    At the PC end, I'm using the "PROGACMP Programmer for ARM devices - Version - Cyclone Version"

    I've tried adding:


    WRITE_WORD=C520/4005300E/ ; First half of unlock sequence to WDOG_UNLOCK
    WRITE_WORD=D928/4005300E/ ; Second half of unlock sequence to WDOG_UNLOCK
    WRITE_WORD=FFFF/400FF042/ ; Dummy write to GPIOG_PDOR to burn a clock cycle
    WRITE_WORD=0010/40053000/ ; Disable WDOG in WDOG_STCTRLH[6,5,0]

    WRITE_LONG=78008070/4003F034/ ; SIM_SCGC4: only OSC, MCG on
    WRITE_LONG=07AB7FC0/4003F038/ ; SIM_SCGC5: all on (incl PORTx) bar SLCD
    WRITE_LONG=00000003/4003F040/ ; SIM_SCGC7: DMA,MPU on
    WRITE_LONG=08000000/4003F044/ ; SIM_CLKDIV1: SYSDIV=/1, 2:1:1 mode
    WRITE_LONG=00000000/4003F04C/ ; SIM_FCFG1: FLASHDOZE,FLASHDIS deasserted

    WRITE_LONG=00000100/4004C008/ ; PORTG_PCR2: GPIO (ALT1), no PU/PD
    WRITE_LONG=00000100/4004C00C/ ; PORTG_PCR3: GPIO (ALT1), no PU/PD
    WRITE_LONG=00000100/4004C010/ ; PORTG_PCR4: GPIO (ALT1), no PU/PD
    WRITE_LONG=00000100/4004C014/ ; PORTG_PCR5: GPIO (ALT1), no PU/PD

    WRITE_BYTE=1C/400FF056/ ; GPIOG_PDDR dir'n: all i/p bar G2,G3,G4.

    PARAM=2/400FF042/ ;SPI_CLK port address - GPIOG_PDOR
    PARAM=3/400FF042/ ;SPI_/SS port address - GPIOG_PDOR
    PARAM=4/400FF052/ ;SPI_MISO port address - GPIOG_PDIR
    PARAM=5/400FF042/ ;SPI_MOSI port address - GPIOG_PDOR
    PARAM=6/04050203/ ;pin#s MOSI=ee,MISO=ff,/SS=gg,CLK=hh
    ; G4 G5 G2 G3

    I load the modified algorithm file and object SREC file.

    Basically, I'm not seeing any activity on any lines using the Cyclone, regardless of which PROGACMP command I try. Complete flatline: all lines at logic low.

    I've also tried setting the clocks according to our production setup, although the POR settings ought to be sufficient for basic GPIO. For the record, these changes, between the watchdog and SIM config, comprise:


    WRITE_LONG=00000000/4003E000/ ; SIM_SOPT1: set OSC32CLK
    ;WRITE_LONG=00000000/4003E004/ ; SIM_SOPT1_CFG: POR defaults
    ;WRITE_LONG=00000001/4003F004/ ; SIM_CTRL_REG: POR defaults
    WRITE_LONG=78008070/4003F034/ ; SIM_SCGC4: only OSC, MCG on
    WRITE_LONG=07AB7FC0/4003F038/ ; SIM_SCGC5: all on (incl PORTx) bar SLCD
    WRITE_LONG=00000003/4003F040/ ; SIM_SCGC7: DMA,MPU on
    WRITE_LONG=08000000/4003F044/ ; SIM_CLKDIV1: SYSDIV=/1, 2:1:1 mode
    WRITE_LONG=00000000/4003F04C/ ; SIM_FCFG1: FLASHDOZE,FLASHDIS deasserted
    WRITE_LONG=00000000/4003F06C/ ; SIM_MISC_CTL: POR defaults


    ; Set up PLL for clock
    WRITE_BYTE=04/40064000/ ; MCG_C1: set IREFS
    WRITE_BYTE=80/40064001/ ; MCG_C2: set LOCRE0
    WRITE_BYTE=60/40064004/ ; MCG_C5: set PLLCLKEN0,PLLSTEN0
    WRITE_BYTE=48/40064005/ ; MCG_C6: set PLLS, CHGPMP_BIAS=0x08
    WRITE_BYTE=00/40064008/ ; MCG_SC: POR defaults + FCRDIV=/1
    WRITE_BYTE=40/4006400C/ ; MCG_C7: PLL32KREFSEL = 32k IRC, OSCCLK on
    WRITE_BYTE=80/4006400D/ ; MCG_C8: LOCRE1 set
    ; Now enable PLL
    WRITE_BYTE=82/40064001/ ; MCG_C2: set LP as well


    This makes no difference.

    When I try to use the Test Pattern command (or indeed almost any other), I get:

    "Started. Error reported from part."

    This has to be almost the least useful error message I've ever read from production software.

    If I try a blank-check command, I get the (even less useful):

    "Module byte not erased at address $FFFFFFFF byte is $00"

    ...which is strange, as (again) the SPI lines have not stirred.

    I'm at my wits' end. Help!




    • For clarity: when I say, "I can program the KM14's internal ROM successfully", I am using the same Cyclone unit, without changing connections.

      All tests are 100% repeatable.

      • I should also add that I'm aware a number of the register commands are redundant: not needed for the Cyclone algorithm. These were to bring the configuration closer to our production software configuration, since that's known good.

        The very first configuration I'd tried had just the watchdog, SIM_SCGC5, PORTG_PCRn, GPIOG_PDDR register programming, plus the PARAM=... commands, and achieved (or rather, failed to achieve) exactly the same.

  • I just double checked your configuration and it looks correct. My primary concern right now is the Watchdog. Based on the documentation and your configuration, a single bus cycle needs to elapse and the registers need to be updated within the update window. This may not be possible given how this initialization script is processed. We can develop a custom programming routine for your application that doesn't have these same limitations if you're willing to send us board to test and develop it. Please let me know if you're interested in that type of solution.

    • Thanks, Geraldo.

      The purpose of the dummy write to GPIOG_PDOR, after the WDOG_UNLOCK writes, but before the WDOG_STCTRLH write, was to burn a clock cycle, so that the WDOG_STCTRLH write would happen within the 256 cycle window.

      So, a few questions:

      * The PE_Serial_SPI_Memory_Programming_for_ARM_devices.pdf file does not state that the device is reset as part of running the algorithm, but text (such as in section 5) implies that this is the case. Is it?

      * If not, at which point does the reset occur, since obviously the timing between reset and the execution of the WDOG-defeat writes is rather critical?

      * How much real time is likely to elapse between executing successive WRITE_WORD commands? Is this likely to be more than 256 clock cycles on the target hardware?

      We need as early a resolution of this as possible, as we're already in production, and this will increase our production rate x2-3 per unit once fixed.

      I'm aware that our hardware has been considered a commercial secret, and I've had push-back from senior figures, at the idea of shipping it to other companies. For that reason, I'm keen to try to resolve this by discussion, if possible, before I don armour, grab a sword and wade into melée to try again to win that battle. Also, the delays involved in shipping - unless you've a UK office with development staff - would cause more time loss.

      Do you have any other options/suggestions for resolving this? Anything else we could do in the .ARP file?

      Thanks again.

      • Footnote: I'm aware we could write a small function to do the WDOG reset in assembler, and use SET_PC_AND_RUN= to execute it, presumably with BKPT #0 at the end. If that's the best option for us, please say, and I'll code it myself.

    • I've just added a section (following the pattern in s.7.3 in the document) as follows, replacing the four-WRITE_WORD watchdog code given above:

      WRITE_WORD=4808/1FFFFF00/ ; ldr r0, =wdog_unlock
      WRITE_WORD=4909/1FFFFF02/ ; ldr r1, =wdog_stctrlh
      WRITE_WORD=4A09/1FFFFF04/ ; ldr r2, =const_a
      WRITE_WORD=4B0A/1FFFFF06/ ; ldr r3, =const_b
      WRITE_WORD=2410/1FFFFF08/ ; movs r4, #0x10
      WRITE_WORD=8002/1FFFFF0A/ ; strh r2, [r0]
      WRITE_WORD=8003/1FFFFF0C/ ; strh r3, [r0]
      WRITE_WORD=BF00/1FFFFF0E/ ; nop ;; Burn a cycle
      WRITE_WORD=800C/1FFFFF10/ ; strh r4, [r1]
      WRITE_WORD=2200/1FFFFF12/ ; movs r2, #0x0
      WRITE_WORD=BE00/1FFFFF14/ ; bkpt #0
      WRITE_WORD=BF00/1FFFFF16/ ; nop
      ; wdog_unlock
      WRITE_LONG=4005300E/1FFFFF18/ ; dcd 0x4005300E
      ; wdog_stctrlh
      WRITE_LONG=400FF042/1FFFFF1C/ ; dcd 0x400FF042
      ; const_a
      WRITE_WORD=C520/1FFFFF20/ ; dcw 0xC520
      ; const_b
      WRITE_WORD=D928/1FFFFF22/ ; dcw 0xD928

      It does not appear to make a difference to the behaviour. Still no response on SPI lines.

      Could you please advise on the operating sequence for PROGACMP, with particular reference to when device resets occur? We're currently doing the following:

      1. Run PROGACMP. The Connection Assistant starts up. )We're using the Cyclone on a USB port.)
      2. Power off the device under test (DUT). Wait a few seconds.
      3. Power on the DUT and IMMEDIATELY click the "Connect (Reset)" button.
      4. Load the ARP file as soon as possible afterwards (but human fingers being what they are, this could take seconds).

      If PROGACMP doesn't reset the DUT immediately before executing the ARP, this could be an issue! We can't guarantee to type fast enough to load the ARP file before the POR-preset watchdog timeout (5,000,000 ticks of the watchdog clock).

  • Resolution (with the additional able aid of Edison in Massachusetts, during support request #22608):

    1. The watchdog must be programmed using machine code, poked in with WRITE_xxx= commands and run by SET_PC_AND_RUN=... (see comment #2.2 above).

    2. The PARAM=[1-5]/... commands MUST be 32-bit aligned. The GPIOx_PDOR/PDIR registers on the KM14 are 16-bit, not 32-bit, aligned. As it happened, the LSNybble was 0x2 for these addresses for PORTG. When the CYCLONE attempted word-width writes to an odd-halfword-aligned address, the KM14 hardfaulted. The solution to this was to use 32-bit-aligned addresses in the PARAM commands. This has the effect of writing an additional 8-bit read-only register, and reading and writing an additional 8-bit read/write register too, but by happy coincidence this is benign on the KM14 model that we use.

    I have made some strong recommendations within that support request as to updates PE Micro can make to the documentation, and also to PROGACMP and/or the CYCLONE firmware, in order to prevent others from having these problems.

    In particular, the error message "Error reported from part" is _completely_ unacceptable in the multi-step procedure defined by the ARP file:

    * What error?
    * Which part? (CYCLONE? ARM? SFLASH?)
    * Doing which operation? (The algorithm file has 57 lines of operations, not including S-records, comments and blanks.)
    * At which ARM address?
    * At which SFLASH address?
    * Using which data?

    That one, completely opaque, message cost us a week's production whilst we together resolved algorithm file problems that I could have intuited in minutes without assistance, had I been given the right information by PROGACMP.

Add comment

   Want to comment? Please login or create a new PEMicro account.

© 2017 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement