Posts by MikeQ

    I have external NOR Flash, CFI compliant connected to my STM32f407vgt6. It seems I can not download into
    the external flash. Is there any trick to it? What do I need to do to get it up and running?
    I am using IAR EWARM, but I would like to also use it with a GDB tool chain such as emBlocks, to which
    I would like to switch.

    Hello Segger,

    I have an application using IAR EWARM and SEGGER embOS. I am very satisfied with embOS,
    but I feel I would like to get away from IAR and would prefer GCC.
    It seems J-Link is working very well with it, and samples for Yagarto (Eclipse) or emIDE
    work well too. Also efficiency of GCC seems to be pretty close nowadays.

    Do you guys offer some help, such as porting my embOS based application to one of these
    GCC based tool chains?
    Consulting work (paying for this) is no problem.

    Am I correct to assume you are trying to program the flash of cell phones ?
    If you are, please make sure what you are trying to do is legal.

    On the technical side, things are always similar:

    You should understand the target system:
    Take a look at the schematic and the documentation of your CPU / SOC.
    Make sure the CPU runs at a decent speed (at least a few MHz, not just 32kHz)
    If necessary, enable & select a PLL as clock source.
    Locate RAM (Ideally on-chip RAM, even if it is just a 4KB) in the chip documentation.
    If necessary, use external RAM (usually SDRAM). You may have to setup
    the external bus interface.
    You may also have to setup the external bus interface to program the flash
    since in a lot of cases, it allows per default just reading of flash memory.
    Last but not least, you should make sure the JTAG speed is as
    high as possible (on ARM-S cores with RTCK, Adaptive is usually a good
    choice; if not, 8Mhz or 12MHz is ideal. However, this should be the last step)

    Obviously J-Link can "talk" to your chip.
    The problem is that it can not halt the chip for some reason.
    Most likely cause is that the target CPU has no clock or that
    it is performing a memory access which halts the CPU indefinetly.

    Can you
    a) Check if the CPU has a clock
    b) Check if there is a "WAit" Signal which may be active

    If this does not help, try "rx 0" from J-Link Commander as follows:

    SEGGER J-Link Commander V3.78a ('?' for help)
    Compiled Dec 4 2007 22:18:44
    DLL version V3.78a, compiled Dec 4 2007 22:18:35
    Firmware: J-Link compiled Dec 03 2007 17:15:31 ARM Rev.5
    Hardware: V5.30
    S/N : 1
    Feature(s) : RDI, FlashBP, FlashDL, JFlash, GDB
    VTarget = 3.306V
    Info: TotalIRLen = 4, IRPrint = 0x01
    JTAG speed: 30 kHz
    Found 1 JTAG device, Total IRLen = 4:
    Id of device #0: 0x3F0F0F0F
    Found ARM with core Id 0x3F0F0F0F (ARM7)
    J-Link>speed 2000
    JTAG speed: 2000 kHz
    J-Link>rx 0
    Reset delay: 0 ms
    Reset type NORMAL: Using RESET pin, halting CPU after Reset
    Info: TotalIRLen = 4, IRPrint = 0x01
    Info: Resetting target using RESET pin
    J-Link>

    Does this help ?

    Hi Brad,

    there should be a way to properly reset the CPU.
    The first thing you need to do is set the speed to either adaptive or 5kHz since the CPU starts at 32kHz;
    after that, a Reset with Zero delay should work.

    We had a similar problem on a SAM7S and something like

    monitor speed 5 // Slow speed so we can work with 32KHz
    monitor reset 0 0 // Halt CPU with 0 delay
    monitor MemU32 0xfffffd00 = a5000004 // Reset peripherals ... Note that a5000005 may also work (resets also CPU, MMU, caches)
    ... // Set up PLL
    monitor speed adaptive

    fixed it. (Without comments, I am not sure they work)
    In general, performing a RESET using 0xFFFFFD00 (for CPU and peripherals) should be the best solution once the CPU is halted.
    If the MMU is enabled and a non-flat mapping (virtual memory != phys. memory) is used, then the MMU may need to be disabled.
    However, something along that line (see above) should work fine.

    Can you give it a shot and post results ?

    --Mike

    Hello Yumbrad,

    just for my understanding:
    When you develop on a Linux host, can't you connect to the GDB Server running on an other (Windows) machine (via TCP/IP) and would
    not that be a solution ? Or running the GDB Server in a virtual Windows machine on the same physical machine ?
    Or is the problem simply that you do not want to use Windows at all ?

    Thanks,
    Mike

    Hello,

    embOS V3.32e is not the latest version, but there is no known problem with this version.

    Most likely a part of the stack is overwritten for some reason; maybe by an other task.

    This is how you can find out:
    - Start the program
    - Wait until the free stack space is reported to be low
    - stop the CPU
    - look at the memory

    You should see that the the stack memory has been overwritten.
    If this is repeatable, use a debugger (J-Link ?) to set a watchpoint on
    modification of this memory addr.
    Repeat the process above and see what modifies memory.

    Does this help ?
    What do you see on the stack (Should be filled with a character CD or AA or something) ?

    SHort feedback would be nice.