Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Failed on programming KEA128 when NMI was connected GND through resistance
Tian M. Mar 15, 2016 at 05:53 AM (05:53 hours)
Staff: Takao Y.

  • Hello
    Now Visteon used KEAZ128 and KEAZN32 on its products. It developed the projects based on iAR+JLink. Now it will mass production and will use CycloneMAX within factory. But it found that CycloneMAX can't program the chips.
    Checked its schematics and found that all of the two chips, KEAZ128&KEAZN32, their NMI pins were connected with GND on their boards through resistances when power-on.

    I tried to add "WRITE_LONG=40048004/0000000C/ ;disable NMIE" to disable NMI in *.arp. But still failed on operation(the same operation on standard EVB of KEAZ128&KEAZN32 were good which NMIs are connected nothing).
    Error code on KEAZ128 is 0061 which is "Undefined algorithm header operation, check software and firmware versions" and on KEAZN32 is 3003 which is " Program operation failed or canceled".

    But on the same boards, iAR+JLink could erase/program successfully.

    Could you help to check the algorithms how to accommodate the HW design on KEA128&KEAZN32 whose NMIs were connected with GND through resistance when power-on, since iAR+JLink could operate successfully?

    Thanks
    Oliver




    Comments

  • Greetings,

    This is news to me that any external debugger can erase/program successfully while the NMI pin is held to GND. There is nothing in the P&E algorithm or software or firmware right now that can be changed to bypass the NMI being grounded. We will have to investigate this.

    Right now if you wish to use P&E tools, you will need to get rid of the pull down to be able to flash program.


    Takao Yamada

  • Hello, Takao
    For KEA family, the NMI could be disabled with writting one bit, while its default status is enabled after power-on.
    Whether PEMicro could add the disabled NMI at the beginning of initialization core?
    I checked iAR's and in its download sequence. It downloaded *.out firstly and then run the *.mac. In its *out, some codes were downloaded into RAM. In *.mac, as follow,
    ////////////////////
    setup()
    {
       __writeMemory8(   0x13,       0x40020003, "Memory");   // flash clock divider (BUSCLK frequency - 20MHz > 0x13)
       __writeMemory32(__readMemory32(0x40048004, "Memory") & ~(1UL<<1),   0x40048004,   "Memory");   // SIM_SOPT   &= 0xfd;
       __writeMemory32(0x1BC00, 0xF000300C, "Memory");   // disable flash cache

       /*Vectors   at RAM*/
       __writeMemory32(0x1FFFF000,   0xE000ED08,   "Memory"); //Vector   table   remap   at 0x1FFFF000
    }
    /////////
    it disabled NMI through 'SIM_SOPT &= 0xfd'.

    Even I added the command in *.arp to simulate the scenario, still failed on CycloneMAX.

    Appreciate that you can help on the scenario.

    Thanks
    Oliver

  • Greetings,

    Could you go to Support Page -> Support requests to create a ticket about this? I want our ARM team to look into this and see if we can implement something similar.


    Takao Yamada

  • Greetings,

    Our latest changes should be able to bypass this problem you are seeing. Make sure to update your software and firmware:
    http://www.pemicro.com/downloads/download_file.cfm?download_id=290


    Takao Yamada

  • Greetings,

    Were you able to bypass the NMI issue?


    Takao Yamada

  • Hi, 
    It's good for the issue.
    Thanks
    Oliver

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