SparkFun Forums 

Where electronics enthusiasts find answers.

What are we doing right with Artemis? What are we doing wrong? Let us know here!
User avatar
By robin_hodgson
Strictly speaking, a patch table is not required even if you use BLE. It just means that you will be using the original mask ROM without any bug patches that may have been released. I don't know how the BLE patches are released as I haven't tried to use it yet.

Starting with the changeover from V4 to V5, I started getting "Error Reading from memory address 0x00000100" every single time a program gets flashed. That is an address in the Sparkfun SVL bootloader [0x00000000..0x0000FFFF]. I don't know what is happening. I just ignore it and everything works fine after that.

I do know that you can replicate that style of error message by asking the debugger to access a peripheral that is not powered up. For example, load a program to flash and don't run it, but just leave it sitting at the first instruction in you main(). Then go to the 'Registers' window, click on 'groups', and select 'uart0'. You will see a ton of messages that the same error message about reading memory where all the memory addresses correspond to UART registers. That's because the UART is powered off at that point in main(). If your program turns the uart on at some point, the messages go away and the registers in the UART window populate with real values.

So who knows. It seems like a transient issue that got introduced with the change from V4 to V5, and it appears that you can safely ignore it.
User avatar
By marsfan
I reread your document and figured it out. I forgot to add in the VTOR initialization. That also got my interrupts fully working.

Have you tried unchecking the setting Restrict Memory Access? I stumbled across it while trying to fix my problem. It might fix the issues you were having.

I still get the error with some other stuff, such as the am_util_delay_ms() function. Looking at the code, that seems to be calling something in the bootrom. I suspect that some security feature on the chip, or the Ambiq Secure Bootloader, is blocking the debugger from reading it.
User avatar
By robin_hodgson
Have you tried unchecking the setting Restrict Memory Access?
I have now, and it makes no difference.

I have used the am_hal_flash_delay() routine since I started with Segger and it never caused an issue before. That delay is performed by bootloader ROM code. Something changed between SESV4 and V5 to cause this issue. The specific error I am seeing seems to be completely harmless though.
 Topic permissions

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

long long title how many chars? lets see 123 ok more? yes 60

We have created lots of YouTube videos just so you can achieve [...]

Another post test yes yes yes or no, maybe ni? :-/

The best flat phpBB theme around. Period. Fine craftmanship and [...]

Do you need a super MOD? Well here it is. chew on this

All you need is right here. Content tag, SEO, listing, Pizza and spaghetti [...]

Lasagna on me this time ok? I got plenty of cash

this should be fantastic. but what about links,images, bbcodes etc etc? [...]