Posts by Kenny

I don't believe that first point is true. I had not included that code and wasn't trying to link two sections to the same place. What I had done was define the vector table in C++ as an array and placed that in the section .vector. But I understand that I am asking too much for you to debug this issue without the actual code.

I have the solution above which is based on the code you pointed out so that's fine. If the linker placement issue comes up again I'll submit an isolated project to recreate the problem.

Thank you for the other information.

I was able to link the above and place the bytes correctly but I changed the device to the "allow security" version. Now I'm running in to errors when attempting to download the application.

I realize that I effectively included these bytes but changed to the "allow security" version of the chip which is incorrect. But if I don't define those bytes and place them at 0x400 what will prevent the linker from writing odd data to that special location?

I created a separate assembly file:

.section .flashsecurity, "ax"
BACKDOORKEY:
  .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
FPROT:
  .byte 0xff, 0xff, 0xff, 0xff
FSEC:
  .byte 0xfe
FOPT:
  .byte 0xff
FEPROT:
  .byte 0xff
FDPROT:
  .byte 0xff

Then used the following in my flash placement file:

<!DOCTYPE Linker_Placement_File>
<Root name="Flash Section Placement">
  <MemorySegment name="$(FLASH_NAME:FLASH)">
    <ProgramSection alignment="0x100" load="Yes" name=".vectors" start="$(FLASH_START:)" />
    <ProgramSection alignment="4" load="Yes" keep="Yes" name=".flashsecurity" start="0x400" size="16" />

This is satisfactory but I'd like to understand why my original approach did not work.

Hi Nino,

I am aware of this code. Can you answer my question? Why does that not work? What is the correct way to do this? I don't understand why that wouldn't place those 16 bytes at 0x400.

Can you elaborate on the differences between the "allow security" selection? While I appreciate that you make efforts to ease development it's important to understand what is actually being done by the debugger or the source files that are copied to the project.

Related: What is the option to configure the J-Link to verify the download? The output suggests that 0.000 seconds were spent verifying. I can't seem to find the option. I did find the menu option to do so but I would have found this issue much faster if the flash verify had been enabled. At the moment I am using the J-Link Lite but have a J-Trace Pro in transit for this project. I replaced the firmware on the K64-TWR on-board debugger.

Now that I have purchased a license I'll send a support request and point to this.

Thanks.

I've defined the following in a C++ file and it isn't referenced by anything. I'm just trying to configure the 16 bytes used by the Kinetis K64 flash protection mechanism..

static const U8 _flash_protection[] __attribute__ ((section(".flash_protection"))) =
{
    0xDE, 0xAD, 0xDE, 0xED,
    0xDE, 0xAD, 0xDE, 0xED,
    0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF,
};

I'd like to place it at 0x400 but this doesn't seem to work:

<ProgramSection alignment="4" load="Yes" keep="Yes" name=".flash_protection" start="0x400" size="16" />

It seems to work fine for my vector placement:

<ProgramSection alignment="0x100" load="Yes" name=".vectors" start="$(FLASH_START:)" />

I'm using MacOS SES 4.10a.

Thanks.

I'm using SES 4.10a on MacOS. It generates <ProjectName>_<Configuration>.jlink files when I start a debug session. For example: SPA_Debug.jlink. These are formatted as so-called settings files rather than script files and I read that the settings files are deprecated.

Why then are these still generated?

Is there an option to specify a path to this file or to suppress them?

Thanks.

I believe the J-Trace Pro operates 4 lanes at 150 MHz but that it is double data-rate so 4 at 300 MHz. What are the limitations of this device when used with a core running at 600 MHz or above? For example the i.MX RT1050 Cortex-M7 devices from NXP has a maximum clock speed of 600 MHz and some Cortex-A devices clock at over 1 GHz.

Re-reading my own post, there is the original question: Why didn't execution halt on the second hardware breakpoint? Especially if the trace addresses are reliable.

I did eventually resolve this issue. Interrupt code was running in the same block during a program or erase of a sector in that same block. That's why a routine was copied to RAM. This is known problem with these processors but it is not well described in their application note.

Maybe there is a hardware bug of some kind or a limitation of trace that I do not understand. Which to believe? The addresses from trace or that the breakpoint hardware failed?

Yes. Knowing that the addresses are dependable is very helpful. Thank you.

I believe these conditions were satisfied during my last debugging session. I understand that in my original setup, where ReadIntoTraceCache is called in AfterTargetDownload, might have been a problem.

Do you think you can describe how the debugger interacts with the ETM/ETB a little more deeply?

When ReadIntoTraceCache is called does that build a map of addresses and the instructions in memory (at that time of course)? Then the ETM is configured to deliver only addresses to the ETB? The debugger then puts these two pieces of information together? When I look at the trace information can I trust that the addresses are always correct but that the instructions may not be depending on when that call to ReadIntoTraceCache is made?

These are not garbage instructions. They are the correct block copied from flash. I also tried an experiment where I only called ReadIntoTraceCache with the exact amount required for the function and got Unknown Addresses.

My target processor is a Kinetis K64 which has an ETB. I am using trace with Ozone over SWD. At first I was getting Unknown Address in the trace listing and corrected this by adding Exec.Command("ReadIntoTraceCache 0x1FFF0000 0x40000") to AfterTargetDownload().

A block of flash beginning with the function of interest is copied to RAM and that function is called using the appropriate pointer-to-function. The copied block is larger than the function of interest so additional, unused, instructions are copied to RAM as well.

The immediate problem is that trace is suggesting that instructions AFTER the function are being called but, using a hardware breakpoint, the processor does not appear to hit these instructions.

Below is a excerpt from the trace capture. I set two hardware breakpoints. The first is the return (pop of some registers and program counter) from the desired RAM function. This breakpoint works. When I examine the stack I can see that the proper return address will be copied to the PC and indeed it returns to the caller which is in flash. However, a breakpoint set after this never halts the processor.

I'm dealing with a very nasty reset problem and believe a proper trace will help me debug this but I don't trust what trace is telling me. I certainly wouldn't expect code to execute past the POP instruction but then again if it is it might explain the issue.

1FFF0E60 LDRB,"R0, [R3]"
1FFF0E62 AND,"R0, R0, #0x31"
1FFF0E64 MOVS,"R1, R6"
1FFF0E66 POP,"{R3-R5, PC}" <---- HW Breakpoint Hit
1FFF0E68 BLX,"R3"
1FFF0E6A B,"0x0FFF0E58"
1FFF0E6C SUB,"SP, SP, #0x08"
1FFF0E6E MOVS,"R3, #0x00"
1FFF0E70 STR,"R3, [SP, #0x04]"
1FFF0E72 B,"0x0FFF0E6E"
1FFF0E74 PUSH,"{R3-R7, LR}" <--- HW Breakpoint Ignored

I have two timer interrupts which both use OS_Enter/OS_LeaveInterrupt. One has a higher priority than the other. Both are at lower priorities (higher values) than the fast interrupt. My understanding is that these routines disable interrupts that are not so-called fast interrupt. Using a scope I set two GPIOs high when entering these routines and low when leaving. I can clearly see the lower interrupt preempted by that with the higher priority.

From the Cortex-M EMBOS manual:

Quote

OS_EnterInterrupt() has to be used as prolog function, when the interrupt handler should not be preempted by any other interrupt handler that runs on a priority below the fast interrupt priority. An interrupt handler that starts with OS_EnterInterrupt() has to end with the epilog function OS_LeaveInterrupt().

From the RTOS header files where the macros are defined:

Quote

#define OS_ENABLE_INTS_SAVE_IPL() // Not required with Cortex-M, avoid call of OS_EI()

Are OS_EnterInterrupt and OS_EnterNestableInterrupt effectively the same on Cortex-M? Why is my interrupt above being preempted?

Thanks,

Kenny

Silly mistake on my end. I had the 19-pin adapter connected to the Target side instead of direct cable to Target + Trace.

......
I'm not seeing any trace data. Traceport with 4-bit is selected. When I step the Trace LED blinks orange and the debugger stepping is definitely slower. If I run the Trace LED is always orange. This is a custom board.

J-Trace for Cortex-M V3.2
SES 3.10i
OS X 10.11.6 (El Capitan)

It's 500/500 ms. It does this when disconnected from the target altogether. Had no functional issues all weekend while debugging. Actually the red/green is appropriate for the holidays.

Hi,

I have a JLink Plus V9.3 attached to a new board containing an STM32F746 and the red LED is flashing at 1 Hz. The manual suggests that this is a fatal error. So far things seem to be working correctly. The board brings out trace to the 19-pin Cortex connector.

Thanks,

Kenny

There is no application but DHCP is working and acquires a lease. PHY address was set to 1 by default in Cube rather than 0.

I used the ST Cube software to export source as an Atollic TrueStudio project and imported it into SES. My goal is simply to get the LWIP stack up and running with FreeRTOS on the STM32F746 Nucleo board. This first commit will build and prints 'Hello' once a second to the output window using RTT. My next step is to see if I can one of the basic LWIP demos to run. Maybe it will right away but if it doesn't then perhaps others may be interested to help me get this going. If nothing else you may read my notes on creating the project (see below).

Normally I spend a lot of time organizing the source of a project. I'm not worried about this too much on this project and, more or less, left them where the tools dropped them.

No disrespect intended to Segger EMBOS or their networking stack. I've selected and am using EMBOS at my day job (also with SES)!

https://github.com/razed11/nucleo

Notes on getting from Cube to SES:

https://github.com/razed11/nucleo…Information.txt

It would be useful if one could recursively convert a dynamic folder to a regular one. Also would it be possible to exclude an item in a dynamic folder from a build?

I'm exporting code from ST Cube, creating an SES project, then importing that code using dynamic folders (because there are many and they are deep). I would like to exclude the vectors and reset handler and use those provided by SES. As it stands the easiest thing to do is remove those unwanted files (or at least move them to a folder that is not included). Nicer to see where they originally were and that they were explicitly excluded.

Thanks.