Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Multilink Universal S08QE32 and random Could not write breakpoint to hardware Error
. Dec 12, 2016 at 09:49 AM (09:49 hours)
Staff: Zahar R.

  • Hello, I am receiving "random" debug error message while stepping. I can normally step C source and after getting that error is target running. After target reset, stepping works, until next error. When breakpoint is places in C source and then "runned" it stops as expected. After few steps it failers.

    I am using WIN7 + classic CW and all latests patches found ad pemicro.com.

    Related part of log:

    ...

    STARTED
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED

    Error: Could not write breakpoint to hardware.

    (CTRL+R pressed)

    Frequency change to ~24837662hz.
    STARTED
    RUNNING
    Preset breakpoint encountered.
    Breakpoint
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED

    Error: Could not write breakpoint to hardware.
    ....

    Including initial portion:

    Frequency change to ~4500000hz.
    Frequency change to ~4973992hz.
    Frequency change to ~4184901hz.
    CPU reset by debugger.
    executing .\cmd\BDM_P&E_Multilink_CyclonePro_reset.cmd

    !// After reset the commands written below will be executed
    HALTED
    done .\cmd\BDM_P&E_Multilink_CyclonePro_reset.cmd

    Reset command file correctly executed.
    RESET
    TRACED

    Error: Could not write breakpoint to hardware.

    STARTED
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED
    TRACED

    Error: Could not write breakpoint to hardware.
    ...




    Comments

  • Greetings,

    1) How many breakpoints are you using typically in a debug session?

    2) Do you find a pattern of when this problem occurs? For example, if you stepped over and over on code that simply does a loop with i++, does this error occur? Or do you find that the problem occurs when stepping through clock initialization, or watchdog feeding, etc that typically is time-sensitive?

    3) Is the watchdog disabled in your code? Or do you have to feed it on a regular basis and have an interrupt to handle it?


    Takao Yamada

  • 1. I take in account number of S08 breakpoints. This happened even use just 1. I also tried to use more - same result. But these is one different thing, which doesn't occured under XP (previous installation, without latests service packs from pemicro.com). I can se MANY breakpoints wihout getting GUI error. As far I remember, I got GUI error, when breakpoints count excess BDC possibilities. From my POV it's like debugger 'forgot' limit of breakpoints. Another small thing: stepping 'next assembly line' works w/o problem. I assume it doesn't run target, by it issue step directly to BDC.

    2. I tested with current souce code (virtual serial port driver) - and after breakpoint (TPM overflow handler, port tick) I can press F10 exacly 13x times. Then I see:

    STEPPED OVER

    Error: Could not write breakpoint to hardware.

    STARTED

    I created small test:

    void foo(void) {

    char x;

    __asm bgnd;
    x=0;
    for (;;) x++;
    }

    I called 'foo' as first instruction @ main (after bootloader setup IO's, disabled WD, ...). When compiled & burned it works. I can 'step' forever. I changed program to:

    void foo2(void) {

    __asm nop; // just to force compiler to generate call
    }

    void foo(void) {

    char x;

    __asm bgnd;
    x=0;
    for (;;) { x++; foo2(); }
    }

    and it still worked. I used same 'firmware' just add this test to the beginning.

    I noticed one thing:

    When stepping "foo" - I get in log window:

    Preset breakpoint encountered.

    When steeping my vserial_tick - I just get "STEPPED OVER" *without* that. Both procedures are places @ address $8xxx

    3. Yes, there is:

    ; disable watchdog
    lda SOPT1
    and #%00111111
    sta SOPT1

    at bootloader.

    There is nothing interested in code - just some HW initialization and IRQ enabling. I have IRQ disabled during step.

    Thank you !

    R.

  • I also tried disable option 'disable interrupts while stepping' (to enable INT's) - and same result. Exacly 13 steps.

    R.

  • Greetings,

    A. Are the 13 steps always running the same code? If so, try stepping different parts of your code and see if you get past 13 steps.

    B. Another thing to try is increase the foo loop to have 13 or more instructions and see if you can step through the entire loop. For loop with one instruction is not using many breakpoints.

    I think we are headed in the right direction. Thank you for running these tests to help narrow down the problem.


    Takao Yamada

  • I changed code to:

    void foo2(void) {

    __asm nop; // just to force compiler to generate call
    }

    void foo(void) {

    char x;

    __asm bgnd;
    x=0;
    for (;;) {

    x++;

    foo2();

    np_delay_ms(10);
    }
    }


    np_delay_ms is just exact ms delay, loops with nops, nothing more. Everything works. It get me idea, to repeat EXACTLY what I am doing in real debug.

    I removed bgnd instruction. Now my EXACT steps are:

    1. compile source -> it runs some bash scripts (cygwin), which get S19 file, add bootloader, CRC's and other things (custom build steps under CW)
    2. open by F5 debuger
    3. reply NO to 'burn'
    4. open generated S19 file
    5. burn
    6. open original .abs file
    7. RESET (this is important) - ctrl + r
    8. place breakpoint to foo()
    9. run

    When this is done with 'bgnd' instruction, it seems things works. Step [7] is necessary because of CW moved automatically to 'main' and skips bootloader (CPU init). CTRL+R resets to FFFE/FFFF vectors.

    Now I get error. Log (from CTRL+R):

    Frequency change to ~25000000hz.
    STARTED
    RUNNING
    Preset breakpoint encountered.
    Breakpoint
    STEPPED OVER
    STEPPED OVER

    Error: Could not write breakpoint to hardware.

    STARTED
    STEPPING OVER
    RUNNING


    When I put bngd back -> it works. LOG:

    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED


    but I found the problem itselfs probably:

    Now I press F5 (RUN). After a while F6 (STOP). I end in delay provedure (ASM). I press F11 (STEP OUT). Now I am @ Foo. Works.

    Another try:

    Now I press F5 (RUN). After a while I put brakpoint into Foo - at x++ (mouse action :) And voala - error. I cleared log before setting breakpoint. Complete log after:

    Preset breakpoint encountered. <- reached x++
    Breakpoint
    STEPPED OVER

    Error: Could not write breakpoint to hardware.

    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered. <- reached x++ again
    Breakpoint


    Because I think it is related to bgnd instruction I tried following:

    run and keep it runing. Add breakpoint to x++. Now we should get error after few lines. Instead of F10 i moved CPU to BGND instruction and step (to execute it). And it doesn't help. So, executing bgnd itselfs doesn't help.

    Next try:

    again clean run. Set BP to x++; Now I moved PC to 1 instruction BEFORE bgnd. and RUN target (pushh generated by CW into foo). And... Everything works :) Complete log (cleared when running):

    Preset breakpoint encountered.
    Breakpoint
    STARTED
    RUNNING
    ILLEGAL_BP
    STEPPED OVER
    STEPPED OVER
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STEPPED OVER
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STEPPED OVER
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STARTED
    STEPPING OVER
    RUNNING
    STOPPED
    STEPPED OVER
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    STEPPED OVER
    STARTED
    STEPPING OVER
    RUNNING
    Preset breakpoint encountered.
    STOPPED
    ....

    You can see 'Preset breakpoint encountered.'

    As the result:

    When breakpoint in source code is reached (runtime BP) - it stops working and log is missing "Preset breakpoint encountered." line. After some steps - it displays error and run target. Running targets "help" - and after reaching BP we got another few steps :) But when bgnd is executed everything works fine. Log contains "Preset breakpoint encountered." during steps.

    Hope this helps.

    R.

  • Forgot to reply [A]: yes, it executes same code raised as timer interrupt. It seems it is related if it executed BDC 'step' or it is forced to create 'breakpoint'. Because virtual serial is mostly step machine, some of lines are exacly 1 instruction long. So, 13 steps may be cuased by that. I tested and result follows:

    9 steps (different machine state - different code way) until error. When machine is stable, 9 steps are stable too.

    When I looks at source and count necessary 'run' and 'step' (as BDC instruction) it gets me contant value unrealted to code flow: 9 "complex" steps. That's why previously I get 13 steps (4 single 'asm' line generated).

    I am not 100% with counts, but I am sure it is related to type of 'step'.

    R.

  • And another hint: when 'more' breakpoints in source code is used (2 including and more) - when target is runned log contains: Error: Could not write breakpoint to hardware.

    As the result - only ONE breakpoint could be used at source code. And it ignores others. They could be seen under 'Control points'. No other watchpoints/markpoints used.

    When using exacly one - it works.

    R.

  • Previous post get me idea, why 'different' count of steps occured (9/13/...). It is maybe unrelated to 'simple' code in meaning of length. But probably to 'IF' like statement - when 2 breakpoints are necessary to set internally.

    I tested following code:

    void foo(void) {

    char x;

    __asm bgnd;

    x=0;
    for (;;) {

    x++;

    if (x & 1)
    foo2();
    else
    np_delay_ms(10);
    }
    }



    Log looks (cleared @ bgnd, after reaching):

    STEPPED OVER
    STEPPED OVER
    STEPPED OVER

    Error: Could not write breakpoint to hardware.

    STARTED
    STEPPING OVER
    RUNNING

    Step at 'foo2()' (first cycle) produces error.

    I think it can't be simpler :)

    So, from my POV: when 2 breakpoints are places at 'if' it failures.

    And another STRANGE thing: AFTER restart realtime debuger - it works !!! I can 'step' that procedure forever.

    But when I place breakpoint into source core - to bgnd - while staying at x++ (log clear at thsi point):

    STEPPED OVER
    STEPPED OVER

    Error: Could not write breakpoint to hardware.

    STARTED
    STEPPING OVER
    RUNNING

    in>

    Error again. From NOW - it produces error EVERY TIME, even breakpoint is deleted (and controlpoints is completly clear). Until RESTART.

    It sounds like 'breakpoint low level deletion leak' :)


    R.

  • Greetings,

    Great investigative work. I will bring this up to our development team and see if we can reproduce and resolve this issue. I will let you know the time frame of which this could be resolved.


    Takao Yamada

  • Greetings,

    I believe the max number of breakpoints for 9S08 chips is 2. And one is used for C-level stepping. If you only placed one breakpoint, are you able to do C-level stepping without issues? If you placed two breakpoints, then start C-level stepping is that when the problem starts to show up?


    Takao Yamada

  • Yep, it have A/B comparators and various modes to 'match'. On the other side, CW with PE under XP (32bit) was abble to use breakpoints _and_ trace together. I am using this combination for looong time. This behaviour is 'new' for me. Also, behaviour is changed in dependency of system reset/bgnd instruction and restart of debuger. So, it is unrelated to HW itselfs, when 'it can work'.

    So, depends on situation: 1 'C' breakpoint + 'C' trace works.

    I will check tomorow older behaviour and let you know limits under XP. I am sure, there wasn't kind of this issues.

    Maybe it is related to way, how CW 'trace' C proram.

    Thank you ! :)

    R.

  • Greetings,

    Any update on this? Were you able to find the differences between XP and Windows 7 on the behavior you saw?


    Takao Yamada

  • I finally tested XP behaviour, and I can confirm, that everything works fine. We tested here exacly same code and we *never* get that error. If we used MORE breakpoints, than HW currently could hold, CW shows message box with error: Could not set the hardware breakpoint at address xxx. It was tested with: Version 6.1 Build 10105 and Windows XP Professional 2002 SP3.

    Let me know, if there is some 'log' or whatever what could help. Also, we all have installed visual C and other debug tools. So, if you would liek to get some infos, not a problem.

    Thank you

    R.

  • Greetings,

    On Windows XP, did you install the patch found on our website? Or did you only do that on the Windows 7 system?


    Takao Yamada

  • One thing you should try is backing up files of Codewarrior in your XP machine and try inserting the patch. If this causes the same problem, then we know the patch is the cause of the problem and has nothing to do with operating systems or other 3rd party software.


    Takao Yamada

  • Good point - no patch installed in XP since it worked without patch. Do you wish to get some exact version of DLL's ?

  • Greetings,

    Sure, if you check out the P&E folder in your classic Codewarrior you should find the DLL and get the version in its properties. What I am looking for is the version on ICD08Z_dll.dll. This is our debugger DLL for S08 devices, which is what we are after. All the other DLL are for simulators, flash programming, or other chip supports.


    Takao Yamada

  • Under Win7, I have files located here: C:\Dev\CW6.3\prog\P&E (I hate like spaces and looong contents at PATH vars). There are following files:

    ICD08z_dll_v165.dll
    ICD08z_dll_v168.dll
    ICD08z_dll_v515.dll
    ICD08z_dll_v584.dll

    V584 is actually used, when CW runs (the only file which can't we openned for writing). It's version INFO is:

    FILEVERSION 5,84,0,0
    PRODUCTVERSION 5,84,0,0
    FILEFLAGSMASK 0x3F
    FILEFLAGS 0x0
    FILEOS VOS_UNKNOWN | VOS__WINDOWS32
    FILETYPE VFT_APP
    FILESUBTYPE 0x0
    {
    BLOCK "StringFileInfo"
    {
    BLOCK "040904E4"
    {
    VALUE "CompanyName", "P&E Microcomputer Systems, Inc."
    VALUE "FileDescription", ""
    VALUE "FileVersion", "5.84.0.0"
    VALUE "InternalName", ""
    VALUE "LegalCopyright", ""
    VALUE "LegalTrademarks", ""
    VALUE "OriginalFilename", ""
    VALUE "ProductName", ""
    VALUE "ProductVersion", "5.84.0.0"
    VALUE "Comments", ""
    }
    }
    BLOCK "VarFileInfo"
    {
    VALUE "Translation", 0x409, 1252
    }
    }

    Under XP:

    ICD08z_dll_v165.dll version 1.65.0.5
    ICD08z_dll_v168.dll version 1.68.0.0


    Ray

  • Greetings,

    Could you open the ngs_devices_hcs08.ini inside your P&E folder and find the entry for your device "9S08QE32" and see which "ICD" dll it is using for XP machine. I want to know specifically which of the two you mentioned is actually being used.


    Takao Yamada

  • W7:

    [9S08QE32]
    PROG=prog08z_dll_v584.dll
    PROG_INTERACTIVE=prog08z_interactive_dll_v584.dll
    FLASHALG=9S08QE32.S8P
    FLASHALG_DESC=Low Voltage, Low Speed
    NUMALTALGS=1
    FLASHALG1=9S08QE32_HighSpeed.S8P
    FLASHALG1_DESC=High Speed
    FULLSIM=ics08dll_icsS08qe8_v108.dll
    ICD=icd08z_dll_v584.dll
    MCUID=105B
    NUMRAMRANGES=1
    RAM0BEGIN=80
    RAM0END=87F
    REGISTERMASK=P&E\S08QE32*.reg

    So, openning for writing works as expected :)


    XP:

    [9S08QE32]
    PROG=prog08z_dll_v169.dll
    PROG_INTERACTIVE=prog08z_interactive_dll_v169.dll
    FLASHALG=9S08QE32.S8P
    FLASHALG_DESC=Low Voltage, Low Speed
    NUMALTALGS=1
    FLASHALG1=9S08QE32_HighSpeed.S8P
    FLASHALG1_DESC=High Speed
    FULLSIM=ics08dll_icsS08qe8_v108.dll
    ICD=ICD08z_dll_v165.dll
    MCUID=105B
    NUMRAMRANGES=1
    RAM0BEGIN=80
    RAM0END=87F
    REGISTERMASK=P&E\S08QE32*.reg

    R.

  • Hello, I am just posting another example of 'bug' with another board and different CPU. This time it is S08LG32. Actually, it bugged me at this simple procedure:

    // delete port (including group)
    void gport_init(uintb id) {

    uintb iold,dev_id;

    if (id>=HAL_GPORT_COUNT)
    return;

    iold=np_interrupts_disable();

    dev_id=ports[id].dev_id;

    // no group
    if (!dev_id) {

    gport_init_phy(id);
    }
    // delete port belongs to device -> delete whole group of I/Os
    else {

    uintb t;
    hsGPortData port;

    for (t=HAL_GPORT_COUNT,port=ports;t;t--,port++) {

    if (ports->dev_id==dev_id)
    gport_init_phy(port->id);
    }
    }

    np_interrupts_pop(iold);
    }

    There is nothing interested. If I set BKP at "iold=np_interrupts_disable();" it stops execution when it reached that line. But when press STEP (F10) program is runned. So, it doesn't move to "if (!dev_id) {". Simply log says:

    Preset breakpoint encountered.
    Breakpoint

    Error: Could not write breakpoint to hardware.

    STARTED

    That procedure is:

    #pragma NO_ENTRY
    #pragma NO_EXIT
    #pragma NO_FRAME
    uintb np_interrupts_disable(void) { __asm {

    clra
    bms disabled
    inca
    disabled:
    sei
    rts

    }}


    Generated code (physically used for stepping) could be seen at http://www.unreal64.net/pemicro.png - as the result, simple 'JSR' can't be tracet, when just 1 BKP is present.

    Under XP (another machine, used above) - it works perfectly. Same CPU, same board, same code.

    So, the bug is not related to QE32 CPU or HW or code since this is completly another project.

    Any progress btw ? It is anoying always delete all BKP (o:

    Thank you :)

    R.

  • Greetings,

    No progress. All of our resources are tied up right now. We will start looking at this early next week.


    Takao Yamada

  • Hello, just small question... Guess which one ? :)

    R.

  • Greetings,

    We have been able to replicate the issue on our end. Oddly the issue does not occur on all S08 devices, so it could be the unique paged-memory of the QE128 that may be causing this issue. I have already escalated the issue to a design engineer to take a look at this problem. He has told me he should have time this week to take a look at it.


    Takao Yamada

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