Error ''Invalid ROM table'' for Keil ULINK debug interface

[flyer31]

Posted on January 05, 2012 at 15:52

Hi,

I have the MCBSTM32F400 development board - this worked fine up to now. Now I wanted to write some new complex application (trying to ''re-target'' a USB MSC example of ST for this board). When I loaded the new code (by pressing the debug button in uVision), the loading somehow was not the same as before with the demo application: If I remember correctly, somehow the system tried to load 2 times. Then it switched off the debug mode automatically. Now if I try anything else (also when I try to load the original Keil demo application, or any very simple Blinky example), I get the Error ''Invalid ROM table'' (title of this small error window: ''ULINK - Cortex-M error''). Anybody has any idea, what this means, or how to handle it? #stm32-ulink-keil-cortex

[flyer31]

Posted on January 05, 2012 at 16:00

PS: I also have a ST4Discovery board, with an integrated ST-LINK debug adapter. This board still works without any problems. (But I did NOT try to write my application on this board - as my other application would use SDIO and LCD, it anyway would not run on the ST4Discovery board).

[Tesla DeLorean]

Posted on January 06, 2012 at 00:46

That is an odd error. ie Googling doesn't provide many examples, or solutions.

Consider removing all power from the board and U-Link, and disconnect the USB cable. Reattach the power, cables, and try again. Check voltages. If it is an issue with the JTAG being able to gain control of the board, say from some errant code, or DMA issues, then consider the settings of the BOOTx pins/jumpers. Set the STM32 to boot into the System ROM, this is a more stable/predictable mode where JTAG can gain control, then erase the FLASH. Consider also your OS and Keil versions. Keil UV4 is at 4.23 now. If that fails, pull a J-Link from the draw and try that instead.

[flyer31]

Posted on January 06, 2012 at 02:03

Hi Clive1,

thanks for your post. But I am very sure, that I did not do anything on the hardware. It was just this software. So I am a bit concerned that I somehow destroyed the chip maybe by some wrong initilisation - this could be, as I am not too experienced up to now with the STM32. Of course I use the brand new Keil software - with the older the ST32F400 board will not run anyway. It worked all perfectly, and then from one minute to the next it did not work any more. (For my USB test software, I used the the STM32F4 Discovery Demo project as base, and then programmed the Keil board with it. Probably it would have been better to start with the Keil Demo project). Do you think it is possible to destroy such a chip by wrong configuration settings? (although I was quite careful of course - e. g. I adapted all the LCD addressing functions ...). I do not have a JTAG programmer or some more sophisticated hardware (and unfortunately I never worked with JTAG before, so now experience with JTAG). Next week perhaps I will try with the SWD port of the ST-LINK debugger which is present on the ST32F4 Discovery board, and use this ST-LINK then to connect to the Keil board - hopefully this might work.(hopefully only the ULINK-ME might have a defect, and not the STM32F407 chip on the Keil board - this is BGA, I think completely impossible to repair or analyze).

[flyer31]

Posted on January 06, 2012 at 02:22

I just also tried on another PC, but same problem.

What really is quite nasty, is the ''shortness'' of this error message. Just these 3 words ''Invalid ROM table''. And nowhere in the Keil realm any hint about this message, also not in Google - they seem not to care too much about error messages or unexpected error solving at this company ... .

[Tesla DeLorean]

Posted on January 06, 2012 at 02:35

Well it's pretty hard to totally brick the hardware via software. If it really is a hardware problem, more likely soldering issue, or if you have connected pins which are not 5V tolerant to a higher supply.

More likely some of your code reconfigures GPIO ports, that code can run while the JTAG wrestles control of the processor after reset. This can take a while, so there is a significant window of potential fail. You can ''change the playing field'' by changing the BOOTx pins so it doesn't execute any of your code. Then do a Flash Erase before switching the BOOTx pins back. Also the System ROM should permit programming/erasing via USART1, which is effective at recovering parts.

[flyer31]

Posted on January 06, 2012 at 11:47

Wow, Clive1, what a wonderful hint.

I set the BOOT0 jumper (=''System Memory'', and in the target options / debug page / Settings/ Flash I specified ''erase complete chip'', and then I used the Load Toolbar button in uVision 4 to load down the standard demo software, and then I switched off power, reset the BOOT0 Jumper to default (=''User Flash''), and miraculously now it is working again perfectly. Thanks a lot!

[dcurran2]

Posted on January 09, 2012 at 17:30 check the Keil project on the debugging/utilities tab.  on some of the keil projecta the radio button to load  either update target at start of load application are not set and when the debugger runs it just pulls up the contents of flash I am guessing and as it doesnt match what you want to brings up the error you asked about.

[Tesla DeLorean]

Posted on January 09, 2012 at 18:05

check the Keil project on the debugging/utilities tab.  on some of the keil projecta the radio button to load  either update target at start of load application are not set and when the debugger runs it just pulls up the contents of flash I am guessing and as it doesnt match what you want to brings up the error you asked about.

If that were the case a simple Flash->Erase would be sufficient to nuke the part, no this error sound much more like a JTAG comms issue. Such issues can be a real problem with the ST-LINK adapters. Even with a total mismatch of code between the host and target Keil's debugger is quite capable of stepping through what's actually running on the target. You won't get an intelligent source listing, but it is very effective at stepping into system ROMs or other code for which source is not available. Keil also provides check boxes to control the ''Run to Main'', and scripting via initialization files.

[dcurran2]

Posted on January 09, 2012 at 18:11 It was the simple solution given to me by the UK Keil distributor and it worked.