Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Memory view and monitor
  • From: <Anton.Krug@xxxxxxxxxxxxx>
  • Date: Tue, 28 Jan 2020 18:32:37 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=naD6SpuX88acxuZJHPFwGvxP3G5qvUZJFqw+6k72Unc=; b=KacbxbxXDm76ATkLy2BkAqddrly2saSIVt6/4uWogxpFuSqR+uuLCwIIf9jeBGuR4InGHFOrW3iuoBP7iTcLvvayMaun7b3mVCGBPITwf3mVUbY50iLHLDSItl/U3iXIw3a/QB3HjaVZLBUGe18hKj5ArLBmAPNPxwW2aMo3SjhZLfPFzUjZ7JBAgVWdWBRDQ3CiCwZB1SeAZYc+kq//9gzCnNV0W8nX4SYLaT3eSmUWmhifjJJ9t83RlznOCOe4RGrhLhuJoMAYZLs/NOXJ/nskdaX/c5/zsgDL5upMqTLhROxwy2+N/u+5SHqxl5UgU08C7BUMDxBvQjz/JYEHtw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=ZMIUhh13s6e+yPcjB0SBArjWN8O/N/l/2PEKHuuZ+3RC/xJgsQXAvbc6m8VuSx/bJsdXUbFjOzu6f/tdMvyoMReDltr69gTnHP1ApVZJV/wbRoTi65lDbOGs30N9Um8PyJiiqw6g63smCpknp1Ii6pBZGTxSwuc0IYOKfwqyliuTLWJxe1Do3hPbHcDE2f/7j6R9hTEODntbwrslOsFAYUWJFU4RPla6OhNzXtYJ22CxkL1+sYmNpv8HogZY/3kuqghQkSBK/I+qH7DwGIZPGfEGMCCsKJqJRf37deRpXYn3enCmmjpliqrKlkDXrVz28vOZ70Sm/0hK0lhzxVd5oA==
  • Delivered-to: cdt-dev@xxxxxxxxxxx
  • Ironport-sdr: iPqkWAPX/kEO14iNfsp1kAGzfm1Wc4yhLuuk9NBjVOi8GsqvVOMM0F4cafoqXxDo1h9F8xqQGI PRAa5dpUylnXjLUP6VHVk8DRgO4kOKop/LEQGSL9dRK3jtqz91Cqb3UI2NSEplHtfOK17K+4Mj biu1d2ocAAUUYjrz6uhdrX69GVupg1rb3O2P8tWpPZRES1glc+F97Msmet1pcvTykhJ87Sg80J hWUXoRn9kivzoNX/FjZVFOx/0hXzOOypTg20ARR/eU0onYpoa+YovRakXZ81ouIHNZ9Uozaqp1 G6w=
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Thread-index: AQHV1gc4VZLk+sRvYUaZLoIRvnD85w==
  • Thread-topic: Memory view and monitor


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,

Back to the top