Re: [OpenOCD-devel] Stange behaviour with STM32F7 and freshly built OpenOCD

[Tomas V. <to...@us...>]

Hmm, the gdb 'mem' command needs first to free a mem region by 'delete 
mem /number/' - not too handy.

OpenOCD creates memory map based on address regions of the defined flash 
banks - all other memory
is marked as rw.

But yes, there is way how to describe the aliased ITCM flash region in 
OpenOCD config: use virtual flash driver.

flash bank itcm-flash.alias virtual 0x00200000 0 0 0 $_TARGETNAME 
$_FLASHNAME

On 06.04.2019 16:20, Rocco Marco Guglielmi wrote:
> Thanks for this information. I tried to remap memory region using mem 
> command but the operation fails due to an overlap of memory regions. 
> Why GDB is unable to retrieve the proper map from OpenOCD? Is the map 
> wrong or something else?
> Thanks
>
>
> On Fri, 5 Apr 2019, 17:24 Tomas Vanek, <to...@us... 
> <mailto:to...@us...>> wrote:
>
>     I think the relevant change is the commit
>     81d0b769a65bf15dda2fd51cd4aee50bb0dc16fb,
>     http://openocd.zylin.com/4429
>
>     Before this commit Cortex-M OpenOCD target used hardware
>     breakpoints (FPB)
>     in 'code memory area' 0x00000000-0x1fffffff, soft breakpoints were
>     set above 0x20000000,
>     no matter what breakpoint type was requested.
>
>     After this change hard or soft bkpt type is set as requested from
>     'bp' command or from gdb.
>     The one of reasons for this change was to enable debugging of
>     Cortex-M7 code in non-ITCM RAM (above 0x20000000)
>     with active ICache - hard bkpts are required as setting/removing
>     of soft bkpt doesn't support ICache flush.
>
>     In OpenOCD use 'bp addr len *hw*'
>
>     gdb knows about the flash region(s) from OpenOCD but in this
>     specific case it doesn't know about its remapping.
>     Set the correct memory map by command 'mem addr addr ro'
>     Use 'info mem' to check setting.
>     Or just use 'hbreak' instead of 'break'
>
>     On 05.04.2019 12:32, Rocco Marco Guglielmi wrote:
>>     Thanks for all these hints,
>>     I'll try to provide you more information during this weekend
>>     Ciao,
>>     RM
>>
>>
>>     On Fri, Apr 5, 2019 at 11:56 AM Matthias Welwarsky
>>     <mat...@sy...
>>     <mailto:mat...@sy...>> wrote:
>>
>>         On Freitag, 5. April 2019 10:53:54 CEST Rocco Marco Guglielmi
>>         wrote:
>>
>>         > I thought I was clear. Let me point out some statements
>>
>>         >
>>
>>         > - The code is loaded in 0x0800 0000 (LMA) and executed at
>>         0x0020 0000
>>
>>         > (VMA) in line with Freddie suggestion
>>
>>         > - The flash procedure works as expected (even after error,
>>         on target
>>
>>         > reset the code is executed properly)
>>
>>         > - On a previous version of openocd (Open On-Chip Debugger
>>
>>         > 0.10.0+dev-00226-g1c2e3d41d) we noticed no problem with the
>>         same
>>
>>         > identical code
>>
>>         > - The issue seems related to the inability of OpenOCD to
>>         place a
>>
>>         > breakpoint in the VMA.
>>
>>         >
>>
>>         > To me, it sounds like a regression but I cannot be sure.
>>
>>         You can help debugging this by doing a "git bisect" with
>>         1c2e3d41d as the last known-good revision. This commit is
>>         really quite old, though. It's from December 16th, 2017. You
>>         need to be able to compile openocd from source and run the
>>         test for each bisect step.
>>
>>         BR,
>>
>>         Matthias
>>
>>         > Ciao,
>>
>>         > RM
>>
>>         >
>>
>>         >
>>
>>         > On Fri, Apr 5, 2019 at 10:13 AM
>>         <bo...@el...
>>         <mailto:bo...@el...>>
>>
>>         >
>>
>>         > wrote:
>>
>>         > > Rocco Marco Guglielmi writes:
>>
>>         > > > Hello there,
>>
>>         > > > any hint?
>>
>>         > > > Ciao,
>>
>>         > > > RM
>>
>>         > >
>>
>>         > > Get you linker script right!
>>
>>         > > It is the task of the linker command to flash at
>>         0x08000000 and to run
>>
>>         > > at the other address.
>>
>>         > >
>>
>>         > > Bye
>>
>>         > > --
>>
>>         > > Uwe Bonnes bo...@el...
>>         <mailto:bo...@el...>
>>
>>         > >
>>
>>         > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289
>>         Darmstadt
>>
>>         > > --------- Tel. 06151 1623569 ------- Fax. 06151 1623305
>>         ---------
>>
>>         -- 
>>
>>         Mit freundlichen Grüßen/Best regards,
>>
>>         Matthias Welwarsky
>>
>>         Project Engineer
>>
>>         SYSGO AG
>>
>>         Office Mainz
>>
>>         Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany
>>
>>         Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
>>
>>         VoIP: SIP:ma...@sy... <mailto:SIP:ma...@sy...>
>>
>>         E-mail: mat...@sy...
>>         <mailto:mat...@sy...> / Web: http://www.sysgo.com
>>
>>         _________________________________________________________________________________
>>         Web: https://www.sysgo.com
>>
>>         Blog: https://www.sysgo.com/blog
>>
>>         Events: https://www.sysgo.com/events
>>
>>         Newsletter: https://www.sysgo.com/newsletter
>>         _________________________________________________________________________________
>>         Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066
>>
>>         Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny
>>         (COO)
>>
>>         Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon
>>
>>         USt-Id-Nr./VAT-Id-No.: DE 149062328
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     OpenOCD-devel mailing list
>>     Ope...@li...
>>     <mailto:Ope...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/openocd-devel
>