Memory view and monitor

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory view and monitor

Anton.Krug
Hi,

When I use the memory view and try to access our embedded HW target, I run into issues. Usually, it's trying to byte read block which is 32-bit aligned and meant for 32-bit accesses. Sometimes it goes into regions which are not implemented and causing exception on the target. And when there is peripheral and there are side effects attached with a read it might not just trigger them, but trigger them more often than expected (as one 32-bit register will be read as four 8-bits).

I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?

I know the read/writes with side effects can be addressed with SVD, which could be great solution for a lot of cases if there would be an option to dictate the bus width accesses and they wouldn't be proxied to 8-bits all the time.

I'm worried that there is no such settings, so probably we should implement this feature and try to upstream it to the CDT. Then there is a follow-up question, what would be the best way to approach this? It needs to be vendor-neutral, what works for us might be no good for others, so hard coding 32-bit accesses is bad. There needs to be a description of region blocks, what is their alignment/data-width, valid address range, some global access privilege (read-only for roms etc...) and then maybe use it with SVD to give finer detail. Maybe the whole region is unimplemented and non-accessible, except few peripherals etc... Should the memory view have a schema similar to SVD to describe this target properties so then it would know how to correctly access given addresses? Probably basic functionality first and then later more detailed/finer/edge-case features.

And we do not want to make own forks, so I'm trying to figure out what it would have to do/contain and do to be upstremable and if anybody has ideas what would be a nice user friendly and easy way to achieve this for everybody?

Best regards,
Anton

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Liviu Ionescu-2


> On 28 Jan 2020, at 20:32, <[hidden email]> <[hidden email]> wrote:
>
> ... When I use the memory view and try to access our embedded HW target, I run into issues.

I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

I remember in the GME Peripheral Registers viewer I had to be extra careful with access sizes and alignments, and I'm not sure I correctly covered all cases, especially those reads with side effects, that must not be performed with all refreshes.

So in this area some extra work might be needed.


Regards,

Liviu








_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Jonah Graham
> I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?

I think you can do this in the Debugger Console (or gdbinit)[1]:
mem 0 0 rw 32 cache

---

> I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

This is an interesting topic. As far as I understood, this topic involves GDB and downstream tooling. For example, even if CDT's memory view "understood" memory alignment and allowable regions, that would not help users who typed in the Debugger Console, nor would it prevent derefrencing pointer variables to the same memory. In both of these cases CDT's memory view is not involved. 

The way to inform GDB what is safe and what alignment, etc, is to use GDB's mem and related commands[1]. Does that set of commands address your needs? If so, then what may make sense is to provide UI in CDT to setup GDB if the GDB and its associated backend don't have support for that already. And, even if GDB and its backend support memory regions, then UI to visualize that would be useful, within the Memory view or in a dedicated UI/view.

Finally, it would not surprise me if there are some flow and presentation issues in the Memory views when memory regions are defined. I hope that fixing such issues are not controversial and can be for the common good.


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 28 Jan 2020 at 16:37, Liviu Ionescu <[hidden email]> wrote:


> On 28 Jan 2020, at 20:32, <[hidden email]> <[hidden email]> wrote:
>
> ... When I use the memory view and try to access our embedded HW target, I run into issues.

I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

I remember in the GME Peripheral Registers viewer I had to be extra careful with access sizes and alignments, and I'm not sure I correctly covered all cases, especially those reads with side effects, that must not be performed with all refreshes.

So in this area some extra work might be needed.


Regards,

Liviu








_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Liviu Ionescu-2


> On 29 Jan 2020, at 03:37, Jonah Graham <[hidden email]> wrote:
>
> > I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?
>
> I think you can do this in the Debugger Console (or gdbinit)[1]:
> mem 0 0 rw 32 cache
>
> ---
>
> > I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(
>
> This is an interesting topic. As far as I understood, this topic involves GDB and downstream tooling.

If I understood Anton's message right, this does involve the CDT debugging plug-ins.

Let me try to rephrase (Anton, please correct me if I'm wrong):

When a memory view is created, the user needs to enter an address and possibly some formatting info. The CDT plug-in then fetches content from a range of addresses and displays it. Each time execution stops, the view is refreshed.

This works fine for reading RAM in a user space linux/windows application, but has some challenges in an embedded environment.

For example, since there is only a begin address and no end address, and the plug-in tries to fill a screen page, creating a memory view with the address of the last word in the RAM space will generally try to read past the physical memory end possibly throw an exception.


Same for the access size, there is no way to ask the plug-in to issue access of 4 bytes, so it can issue requests of any size.


It is true that the reads are performed by GDB, but the range of the accesses and the granularity is controlled by the plug-in.


In other words, simply specifying the begin address is not enough, probably it would be safer to add the end address, word size and the alignment.


The GME Peripheral Registers viewer is inspired by the memory viewer, but since it has a better knowledge of the hardware from the SVD, it can issue accesses that match the registers sizes, and can also avoid going into non defined areas.


Regards,

Liviu




_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Liviu Ionescu-2
In reply to this post by Jonah Graham


> On 29 Jan 2020, at 03:37, Jonah Graham <[hidden email]> wrote:
>
> > I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?
>
> I think you can do this in the Debugger Console (or gdbinit)[1]:
> mem 0 0 rw 32 cache
> ... use GDB's mem and related commands[1].
> [1] https://sourceware.org/gdb/current/onlinedocs/gdb/Memory-Region-Attributes.html#Memory-Region-Attributes

Ah, it took me a second read to understand your proposal.

You mean to issue some commands to GDB (probably in the debug configuration page) to inform it on the actual memory regions characteristics, and then be sure that the memory viewer gets these characteristics back and issues accesses accordingly.

I don't know how complicated this might be, but I think it is worths investigating.


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Anton.Krug
In reply to this post by Jonah Graham
> mem 0 0 rw 32 cache
Should this affect the alignment and accesses how the memory viewer accesses the data?

info mem
Using user-defined memory regions.
Num Enb Low Addr   High Addr  Attrs
1   y   0x00000000 0x100000000 rw 32 cache

And the memory view is still doing byte accesses anyway, or am I doing something stupid?

I wouldn't say the downstream tooling necessary needs to know. If the memoryview could fetch the mem regions from the gdb then it would be great. But this doesn't have to make 100% robust accesses from all levels, sometimes you want to do odd stuff, sometimes you want to on lower level go into the unimplemented region, or trigger an exception. This is more to safeguard the basic usage where just a simple opening of the memory view can break the system.

We do a bit of this on our arms where we set what regions are read and which are read/write so the OpenOCD knows better what types of breakpoints are safe where. Before these things were hardcoded, but it was not suiting our HW as it was more configurable and different than typical ARM targets. So be able to describe the peripheral regions and whatnut through this would be great. But I understand it correctly that memory view now is not fetching the info mem information? Instead of inventing new scheme using the gdb mem would be great. The configuration doesn't have to UI, if there is a way to make sure first it works well.

Then for finer granularity detail (what registers are safe to read/write and what side effects they have) would be good to do on the SVD/Peripheral gme-packs level. Liviu, is this what you are referencing 'GME Peripheral Registers viewer', or is there something else as well? I tried the packs and made a specific peripheral and then the peripheral open in the memory view, so it is inheriting the issues of the memory viewer? Except that the SVD looks perfect.

From: [hidden email] <[hidden email]> on behalf of Jonah Graham <[hidden email]>
Sent: 29 January 2020 01:37
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?

I think you can do this in the Debugger Console (or gdbinit)[1]:
mem 0 0 rw 32 cache

---

> I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

This is an interesting topic. As far as I understood, this topic involves GDB and downstream tooling. For example, even if CDT's memory view "understood" memory alignment and allowable regions, that would not help users who typed in the Debugger Console, nor would it prevent derefrencing pointer variables to the same memory. In both of these cases CDT's memory view is not involved. 

The way to inform GDB what is safe and what alignment, etc, is to use GDB's mem and related commands[1]. Does that set of commands address your needs? If so, then what may make sense is to provide UI in CDT to setup GDB if the GDB and its associated backend don't have support for that already. And, even if GDB and its backend support memory regions, then UI to visualize that would be useful, within the Memory view or in a dedicated UI/view.

Finally, it would not surprise me if there are some flow and presentation issues in the Memory views when memory regions are defined. I hope that fixing such issues are not controversial and can be for the common good.


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 28 Jan 2020 at 16:37, Liviu Ionescu <[hidden email]> wrote:


> On 28 Jan 2020, at 20:32, <[hidden email]> <[hidden email]> wrote:
>
> ... When I use the memory view and try to access our embedded HW target, I run into issues.

I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

I remember in the GME Peripheral Registers viewer I had to be extra careful with access sizes and alignments, and I'm not sure I correctly covered all cases, especially those reads with side effects, that must not be performed with all refreshes.

So in this area some extra work might be needed.


Regards,

Liviu








_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Liviu Ionescu-2


> On 29 Jan 2020, at 17:06, <[hidden email]> <[hidden email]> wrote:
>
> Then for finer granularity detail (what registers are safe to read/write and what side effects they have) would be good to do on the SVD/Peripheral gme-packs level. Liviu, is this what you are referencing 'GME Peripheral Registers viewer', or is there something else as well?

As far as I know, there is only one GNU MCU Eclipse Peripherals Registers viewer.

> I tried the packs and made a specific peripheral and then the peripheral open in the memory view, so it is inheriting the issues of the memory viewer?

Well, if you open the memory viewer, yes, it does not know of the registers, only the peripheral registers viewer is aware of them.


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Jonah Graham
In reply to this post by Anton.Krug

> And the memory view is still doing byte accesses anyway [...]

Is GDB doing byte accesses to the target still? i.e. memory view/CDT will issue -data-read-memory-bytes, but I expect GDB to issue to target aligned word reads to fill that region. The -data-read-memory-bytes uses read_memory_robust which takes into account memory regions which in turn uses target_read which also does.

I don't have a suitable board setup at the moment for debugging/reproducing this.

Jonah 

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 29 Jan 2020 at 10:06, <[hidden email]> wrote:
> mem 0 0 rw 32 cache
Should this affect the alignment and accesses how the memory viewer accesses the data?

info mem
Using user-defined memory regions.
Num Enb Low Addr   High Addr  Attrs
1   y   0x00000000 0x100000000 rw 32 cache

And the memory view is still doing byte accesses anyway, or am I doing something stupid?

I wouldn't say the downstream tooling necessary needs to know. If the memoryview could fetch the mem regions from the gdb then it would be great. But this doesn't have to make 100% robust accesses from all levels, sometimes you want to do odd stuff, sometimes you want to on lower level go into the unimplemented region, or trigger an exception. This is more to safeguard the basic usage where just a simple opening of the memory view can break the system.

We do a bit of this on our arms where we set what regions are read and which are read/write so the OpenOCD knows better what types of breakpoints are safe where. Before these things were hardcoded, but it was not suiting our HW as it was more configurable and different than typical ARM targets. So be able to describe the peripheral regions and whatnut through this would be great. But I understand it correctly that memory view now is not fetching the info mem information? Instead of inventing new scheme using the gdb mem would be great. The configuration doesn't have to UI, if there is a way to make sure first it works well.

Then for finer granularity detail (what registers are safe to read/write and what side effects they have) would be good to do on the SVD/Peripheral gme-packs level. Liviu, is this what you are referencing 'GME Peripheral Registers viewer', or is there something else as well? I tried the packs and made a specific peripheral and then the peripheral open in the memory view, so it is inheriting the issues of the memory viewer? Except that the SVD looks perfect.

From: [hidden email] <[hidden email]> on behalf of Jonah Graham <[hidden email]>
Sent: 29 January 2020 01:37
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?

I think you can do this in the Debugger Console (or gdbinit)[1]:
mem 0 0 rw 32 cache

---

> I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

This is an interesting topic. As far as I understood, this topic involves GDB and downstream tooling. For example, even if CDT's memory view "understood" memory alignment and allowable regions, that would not help users who typed in the Debugger Console, nor would it prevent derefrencing pointer variables to the same memory. In both of these cases CDT's memory view is not involved. 

The way to inform GDB what is safe and what alignment, etc, is to use GDB's mem and related commands[1]. Does that set of commands address your needs? If so, then what may make sense is to provide UI in CDT to setup GDB if the GDB and its associated backend don't have support for that already. And, even if GDB and its backend support memory regions, then UI to visualize that would be useful, within the Memory view or in a dedicated UI/view.

Finally, it would not surprise me if there are some flow and presentation issues in the Memory views when memory regions are defined. I hope that fixing such issues are not controversial and can be for the common good.


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 28 Jan 2020 at 16:37, Liviu Ionescu <[hidden email]> wrote:


> On 28 Jan 2020, at 20:32, <[hidden email]> <[hidden email]> wrote:
>
> ... When I use the memory view and try to access our embedded HW target, I run into issues.

I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

I remember in the GME Peripheral Registers viewer I had to be extra careful with access sizes and alignments, and I'm not sure I correctly covered all cases, especially those reads with side effects, that must not be performed with all refreshes.

So in this area some extra work might be needed.


Regards,

Liviu








_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Anton.Krug
In reply to this post by Liviu Ionescu-2
I followed your document:

And in Peripherals I can select the peripheral I made quickly and then it gets opened as Memory View's monitor, see attachment. Do I do something wrong?
Btw when I target the simulation platform and 'break' it on purpose to support byte accesses then the monitor gets populated nicely with the values.

From: [hidden email] <[hidden email]> on behalf of Liviu Ionescu <[hidden email]>
Sent: 29 January 2020 15:21
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

> On 29 Jan 2020, at 17:06, <[hidden email]> <[hidden email]> wrote:
>
> Then for finer granularity detail (what registers are safe to read/write and what side effects they have) would be good to do on the SVD/Peripheral gme-packs level. Liviu, is this what you are referencing 'GME Peripheral Registers viewer', or is there something else as well?

As far as I know, there is only one GNU MCU Eclipse Peripherals Registers viewer.

> I tried the packs and made a specific peripheral and then the peripheral open in the memory view, so it is inheriting the issues of the memory viewer?

Well, if you open the memory viewer, yes, it does not know of the registers, only the peripheral registers viewer is aware of them.


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

SVD1.png (52K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Anton.Krug
In reply to this post by Jonah Graham
I see, thank you for all the info.
I'm using riscv gcc 8.3 (Liviu's build), I might try Arm and native x86 gdb to understand it better if I do something wrong or it really doesn't work.
When I do not have HW I like to target the Renode simulation platform, it can log me the accesses so I see when the byte accesses were attempted (without breaking the target completely) and I can tweak it to allow the 8-bit accesses to be translated into into 32-bit accesses, so I can see a bit how it could work.

From: Jonah Graham <[hidden email]>
Sent: 29 January 2020 15:27
To: Anton Krug - M31845 <[hidden email]>
Cc: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

> And the memory view is still doing byte accesses anyway [...]

Is GDB doing byte accesses to the target still? i.e. memory view/CDT will issue -data-read-memory-bytes, but I expect GDB to issue to target aligned word reads to fill that region. The -data-read-memory-bytes uses read_memory_robust which takes into account memory regions which in turn uses target_read which also does.

I don't have a suitable board setup at the moment for debugging/reproducing this.

Jonah 

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 29 Jan 2020 at 10:06, <[hidden email]> wrote:
> mem 0 0 rw 32 cache
Should this affect the alignment and accesses how the memory viewer accesses the data?

info mem
Using user-defined memory regions.
Num Enb Low Addr   High Addr  Attrs
1   y   0x00000000 0x100000000 rw 32 cache

And the memory view is still doing byte accesses anyway, or am I doing something stupid?

I wouldn't say the downstream tooling necessary needs to know. If the memoryview could fetch the mem regions from the gdb then it would be great. But this doesn't have to make 100% robust accesses from all levels, sometimes you want to do odd stuff, sometimes you want to on lower level go into the unimplemented region, or trigger an exception. This is more to safeguard the basic usage where just a simple opening of the memory view can break the system.

We do a bit of this on our arms where we set what regions are read and which are read/write so the OpenOCD knows better what types of breakpoints are safe where. Before these things were hardcoded, but it was not suiting our HW as it was more configurable and different than typical ARM targets. So be able to describe the peripheral regions and whatnut through this would be great. But I understand it correctly that memory view now is not fetching the info mem information? Instead of inventing new scheme using the gdb mem would be great. The configuration doesn't have to UI, if there is a way to make sure first it works well.

Then for finer granularity detail (what registers are safe to read/write and what side effects they have) would be good to do on the SVD/Peripheral gme-packs level. Liviu, is this what you are referencing 'GME Peripheral Registers viewer', or is there something else as well? I tried the packs and made a specific peripheral and then the peripheral open in the memory view, so it is inheriting the issues of the memory viewer? Except that the SVD looks perfect.

From: [hidden email] <[hidden email]> on behalf of Jonah Graham <[hidden email]>
Sent: 29 January 2020 01:37
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?

I think you can do this in the Debugger Console (or gdbinit)[1]:
mem 0 0 rw 32 cache

---

> I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

This is an interesting topic. As far as I understood, this topic involves GDB and downstream tooling. For example, even if CDT's memory view "understood" memory alignment and allowable regions, that would not help users who typed in the Debugger Console, nor would it prevent derefrencing pointer variables to the same memory. In both of these cases CDT's memory view is not involved. 

The way to inform GDB what is safe and what alignment, etc, is to use GDB's mem and related commands[1]. Does that set of commands address your needs? If so, then what may make sense is to provide UI in CDT to setup GDB if the GDB and its associated backend don't have support for that already. And, even if GDB and its backend support memory regions, then UI to visualize that would be useful, within the Memory view or in a dedicated UI/view.

Finally, it would not surprise me if there are some flow and presentation issues in the Memory views when memory regions are defined. I hope that fixing such issues are not controversial and can be for the common good.


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 28 Jan 2020 at 16:37, Liviu Ionescu <[hidden email]> wrote:


> On 28 Jan 2020, at 20:32, <[hidden email]> <[hidden email]> wrote:
>
> ... When I use the memory view and try to access our embedded HW target, I run into issues.

I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

I remember in the GME Peripheral Registers viewer I had to be extra careful with access sizes and alignments, and I'm not sure I correctly covered all cases, especially those reads with side effects, that must not be performed with all refreshes.

So in this area some extra work might be needed.


Regards,

Liviu








_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Liviu Ionescu-2
In reply to this post by Anton.Krug


> On 29 Jan 2020, at 17:59, <[hidden email]> <[hidden email]> wrote:
>
> I followed your document:
> https://gnu-mcu-eclipse.github.io/plugins/packs-manager/
>
> And in Peripherals I can select the peripheral I made quickly and then it gets opened as Memory View's monitor, see attachment. Do I do something wrong?

I'm afraid I do not understand the question.

Yes, on Cortex-M devices, the peripherals are memory mapped, and the peripheral registers view is just a more advanced memory view.

What do you expect to happen?

Does it work with other peripherals?

> Btw when I target the simulation platform and 'break' it on purpose to support byte accesses then the monitor gets populated nicely with the values.

... not following you... :-(


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Anton.Krug
The question was just to rule out if we are talking about 2 different things. 
And I was in the mindset it's inheriting the access functionality from the memory view.

Not just Cortex-M, RISC-V can have memory-mapped peripherals as well. The screenshot looks at what I expect to happen (because I enabled 8-bit accesses).
It doesn't work on other peripherals, because that CoreTimer is the only peripheral I modeled for our RISC-V target.
Under 'breaking it' I mean the peripheral is designed to be accessed in 32-bit mode and so does the simulated model of the peripheral, however in the simulated model I broke the spec and allowed it to be accessed in 8-bit chunks as well, then the peripheral view works as shown in the screenshot. 

From: Liviu Ionescu <[hidden email]>
Sent: 29 January 2020 16:46
To: Anton Krug - M31845 <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

> On 29 Jan 2020, at 17:59, <[hidden email]> <[hidden email]> wrote:
>
> I followed your document:
> https://gnu-mcu-eclipse.github.io/plugins/packs-manager/
>
> And in Peripherals I can select the peripheral I made quickly and then it gets opened as Memory View's monitor, see attachment. Do I do something wrong?

I'm afraid I do not understand the question.

Yes, on Cortex-M devices, the peripherals are memory mapped, and the peripheral registers view is just a more advanced memory view.

What do you expect to happen?

Does it work with other peripherals?

> Btw when I target the simulation platform and 'break' it on purpose to support byte accesses then the monitor gets populated nicely with the values.

... not following you... :-(


Regards,

Liviu


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Liviu Ionescu-2


> On 29 Jan 2020, at 19:28, <[hidden email]> <[hidden email]> wrote:
>
> It doesn't work on other peripherals, because that CoreTimer is the only peripheral I modeled for our RISC-V target.
> Under 'breaking it' I mean the peripheral is designed to be accessed in 32-bit mode and so does the simulated model of the peripheral, however in the simulated model I broke the spec and allowed it to be accessed in 8-bit chunks as well, then the peripheral view works as shown in the screenshot.

If the SVD defines the registers as 32-bit, and you see 8-bit accesses, then you probably hit a bug in the GME peripheral registers viewer, I don't think it has to do with CDT.


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Memory view and monitor

Anton.Krug
Yes, I might be overlapping two similar, but different problems.

  1. I will retest the 'mem 0 0 rw' without a peripheral view. And see if the regular memory view works.
  2. And then check my peripheral spec again if I did describe it correctly. To see if the mem-mapped peripherals work.

From: Liviu Ionescu <[hidden email]>
Sent: 29 January 2020 18:09
To: Anton Krug - M31845 <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

> On 29 Jan 2020, at 19:28, <[hidden email]> <[hidden email]> wrote:
>
> It doesn't work on other peripherals, because that CoreTimer is the only peripheral I modeled for our RISC-V target.
> Under 'breaking it' I mean the peripheral is designed to be accessed in 32-bit mode and so does the simulated model of the peripheral, however in the simulated model I broke the spec and allowed it to be accessed in 8-bit chunks as well, then the peripheral view works as shown in the screenshot.

If the SVD defines the registers as 32-bit, and you see 8-bit accesses, then you probably hit a bug in the GME peripheral registers viewer, I don't think it has to do with CDT.


Regards,

Liviu


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev