JLINK MK70FN1M0 TRST signal

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • JLINK MK70FN1M0 TRST signal

    Hi,

    I'm working on K70TWR board with JLINK and CortexM connector.
    Do I need to connect TRST from Legacy JTAG (pin 3) to CortexM connector pin 9 for that device ?
    By looking at the schematic, I observed that the pin 9 is connected to K70 pin PTA4.
    With a closer look at the schematic we can also observe that PTA5 is the TRST pin of the processor.

    I'm asking these question because I'm able to to connect to the device and get CPU ID and see Cortex M4 displayed on JLink GDB server JTAG but I can't read and write to Flash memory.

    Thanks.
  • Here are the other tests that I did.

    JLink is able to write and read data to internal ram using Jlink commander w4 and mem32 command.

    I observed that when trying to write to flash memory with w4 and reading it with mem32, I always reads it as 0xffffffff.
    It's seems that the device is locked. When I saw that, I tried to unlock the device using "unlock kinetis".
    Device still locked even after unlock command.

    Is the unlock command supports kinetis mk70kn1m0xxx12 devices ?

    Thanks.
  • Hi,

    Device still locked even after unlock command.

    I do not think so...
    If a Kinetis device is locked / secured we can NOT connect to it and so we can NOT read/write memory.
    (Otherwise the security would be useless...)

    The w4 command performs a simple write to memory. As long as no device has been explicitly selected
    by the "exec device = ..." command, the memory that is written by the w4 command is assumed to be RAM.

    I am a bit confused what is the problem right now...
    In the title of the thread you initially asked about the TRST signal.
    Then in your first post you wrote that flash programming via GDBServer does not work.
    Now you write that everything basically seems to work but flash programming via J-Link Commander does not and that your device is possibly locked (which can not be the case since then basic operations would also NOT work).

    Did you have a look in UM08001, chapter "Flash download", section "Setup for various debuggers (internal flash)"?
    There are some steps required to enable programming of the internal flash of a device.


    Best regards
    Alex
  • Hi Alex,

    I agree that it's confusing. The issue is that I'm unable to program the application into internal flash.

    Below is the history of the issue that will help you understand the questions that I asked (it was confusing ) and after you will find the steps that i did to program the device.


    Issue History
    Here is a brief history why :
    At first I asked if TRST needs to be connected to the CPU because I taught it was the issue. (that where the thread title comes from)
    After I investigate the issue and figured out that I was able to read/write in internal ram and also that JLINK JTAG recognized the device as Cortex M4.
    The conclusion of that is that all signals are properly connected to CPU because I can read/writre into ram and Jlink recognized the CPU.
    After that, I used Jlink Commander to "unlock kinetis" because I thought that it was the issue (device locked) because the program can't be write in internal flash.

    Issue
    The issue is that I can't write the application into flash memory using the following steps.

    Here is the script that I run to dowload the application "blinky.elf" into internal flash:
    1- First , I start Jlink Gdb server
    2- I type the following command using arm-none-eabi-gdb

    target remote localhost:2331
    monitor interface JTAG
    monitor endian little
    monitor speed auto
    monitor reset
    monitor flash device = MK70FN1m0xxx12
    monitor flash download = 1
    load blinky.elf

    At this point, a the flash download popup screen appears at remains on screen for ever.

    Hope this help to understand.
    Thanks

    The post was edited 2 times, last by mbeakes ().

  • Hi,

    It looks that the issue was not related to the application by itself.
    I tried to load a demo project from Freescale and I got the same result (the popup that shows programmation progress remains on screen).
    I tried the following based on your suggestion and UM08001 p.150 :
    1- convert the application to binary file ex: blinky.bin
    2-open JLink commander and type the following commands:
    exec device = mk70fn1m0xxx12
    loadbin blinky.main,0x00000000

    As soon as I typed these command, the bin was loaded into the device.
    By typing mem32, I was able to read the internal flash and confirm that the bin was loaded in internal flash.

    Now I can write/read internal flash memory.
    I didn't really understand why it starts working after using loadbin.

    Now when I use arm-none-eabi-gdb, I'm able to write/read internal flash memory.
  • Hi,

    Now I am confused again...
    Can you simply provide something that can be used to reproduce the problem you were seeing (flash programming window does not close)?
    Ideally it is just an ELF file, we can use to reproduce this.
    We would REALLY like to understand
    a) Where this problem comes from.
    b) How to fix it.


    Best regards
    Alex
  • K70 program issue

    Hi,

    Here is a simple .elf file who includes boot code.
    This .elf file is a simple boot code that i used for the K70 TWR board.
    This application does nothing special, it setup vector table, flash config bits and copy flash content to internal ram and then jump into the main loop.
    The main loop includes some line of code only to test if I can step in the code using the JTAG.

    As I mentionned before, when I had the issue, I wasn't hable to program the board at all. The progress window (the one that contains 3 progress bars that indicates the download status) remains on screen and the progress bars didn't moved.
    Since the first time that I programmed the device successfully, it's working fine and the issue never showed up again.

    Hope this will help.
    Files
    • main.zip

      (3.5 kB, downloaded 552 times, last: )