How to access *any* memory address without a bus fault?

[gw]

Posted on May 08, 2014 at 11:57

How could I write some code that would access a memory address and wouldn't generate a bus fault if it was incorrect? Or failing that, is there a way to safely check if an address is valid, or maybe even a way to have the BusFault handler return and have normal execution resume?

I'm writing a language interpreter for an STM32F103, and there are some cases when this would be very handy:

• Providing a 'peek' instruction that wouldn't crash the micro if an invalid address was given (presumably some addresses would still cause pain - but it'd be a lot less likely!)
• Checking at run-time how much usable RAM there was, and expanding the stack+heap to use it - because some chips appear to just be re-badged higher end parts (eg. some STM32F103VC chips have 64kb instead of the marketed 48kb) - this is for use by enthusiasts - obviously it wouldn't be relied on for production.

I've tried quite hard to get something working, but haven't had much luck so far - if I return from the Bus Fault handler (even after clearing the flags) the processor immediately HardFaults.

thanks!

[chen]

Posted on May 08, 2014 at 12:09 '' is there a way to safely check if an address is valid'' if( ( address >= valid_addr_start) && ( address <= valid_addr_end ) ) In the embedded world, the processor is known and therefore the address ranges are known. If you are dealing with multiple processors - do a look up

[gw]

Posted on May 08, 2014 at 12:27

That doesn't answer my question I'm afraid.

For instance I have an STM32F103VCT6 here - that should have 48kB of RAM, so accessing 0x2000FFFC should give a bus fault - but it doesn't. In fact the whole 16kB of memory between 48k and 64k is usable.However if I access 1 word further on - 0x20010000 - I get a bus fault.

[chen]

Posted on May 08, 2014 at 12:41

OK - your question is - how do I deal with a BusFault.

My answer is : do not let it get to a bus fault. Sure it can be done - but it will be a lot of effort. What will it gain? What are you really trying to do? ''I'm writing a language interpreter for an STM32F103'' Does it really have to allow probing of all memory - or can you check to see if the memory address is in an allowable range before executing the instruction?

[gw]

Posted on May 08, 2014 at 13:01

The main use for this is to probe the chip to see just how much memory is really available on-chip - regardless of the part number written into the chip's ROM.

If there was some way of finding out exactly how much RAM there was without this, it would be preferable - but it seems that there isn't.So I need to be able to find out whether accessing memory is going to give a BusFault (or I need to be able to disable BusFaults, or handle them).Are there any examples of BusFault handlers that just ignore the BusFault and carry on as normal? I did spend quite some time looking (and trying) but I haven't been able to find one.

[chen]

Posted on May 08, 2014 at 13:28

''The main use for this is to probe the chip to see just how much memory is really available on-chip - regardless of the part number written into the chip's ROM.''

As I said before - in the embedded world (and STM32 parts are used mainly in the embedded world) the part being used is known! However, the information you seek (about faults) is in the ARM programmers manuals : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0440b/Chdbeibh.html (look at the bottom of page - downloadable PDF version) The STM32 customized version : document/programming_manual/CD00228163.pdf I think part of the problem is the definition for the Bus handler ISR. Most compilers if not defined will automatically save registers on entry. For what you want - this must be disabled (preserving the stack for the RTI) - for GNU gcc 'naked' is used - do not know what compiler you are using. I think there was someone else trying to recover from BusFaults to try and determine RAM size in this forum.

[gw]

Posted on May 08, 2014 at 13:51

Thanks for the info - I'd done a quick search before posting, but all I found was this:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/How%20to%20Enable%20BusFault,%20MemManage%20Interrupts

I had looked at the programming manual before too, but had no luck producing a BusFault handler that didn't Hardfault right after returning. Thanks for the info about the 'naked' keyword - does accessing the stack in the BusFault handler cause problems then?

[stm322399]

Posted on May 08, 2014 at 14:15

Are you sure to understand the consequence of this *discovery* process ? There are a lot of questions to answer:

* How do you define 'ignore the busfault and carry on as normal' ? * Let's take this example, you are reading random memory locations; Where there is memory, you got the content of the cell, but what do you expect anywhere else ? A value ? An error ? * You want to find the boundary of the memory, what tells you that you reached the end ? * The busfault handler shall not carry on as normal, you must implement in the handler a way to signal the reading error, don't you ? Perhaps the most simple is to read bytes: normal values are comprised between 0-255, an error would return -1. So the busfault handler must not only ignore the faulty load byte, but also fill the destination register with -1 (you need to decode the faulty instruction). All of this is *possible*, but is eventually not trivial to do.

[gw]

Posted on May 08, 2014 at 15:21

Hi,

I'd be entirely happy with an undefined result - perhaps with the 'ldr' operation actually being a no-op.Assuming I can effectively 'disable' busfaults (either with a handler, or by actually disabling them), I'd just do:

• Write 0xAAAAAAAA to X
• read X and check against 0xAAAAAAAA
• Write 0x55555555 to X
• read X and check against 0x55555555

And I'd probably run it all the way up memory, to ensure that the chip hadn't been classified as a lower spec chip because there was a memory error. I don't think that would cause any problems?

[gw]

Posted on May 08, 2014 at 15:24

Just to add - because of this, the 'ldr'/'str' instruction being a no-op, or with undefined result, is absolutely fine.