problems with writing to memory of STM32 microchips?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • problems with writing to memory of STM32 microchips?

    hello there, im new to microcontrollers and i have just started programming with the STM32 series microchips, i have been reading up on setting outputs on the microchips but i have not been able to personally do it, with all the programs i have included the standard libraries as well as the stm32f103 libraries.

    the problem is that when i set the configuration for a GPIO, and then check the memory space later using J-link commander, the values in the memory space is not modified.

    i have also tried using J-link commander to modify the bits in too but it was of no luck (see attached)

    any advice/help on how to set the output pins (e.g. for GPIOA) to be able to set it high/low or how to solve the memory not changing problem would be greatly appreciated, thanks :D



    p.s. i have tried this and i get the same problem on both a stm32f103rb and a stm32f103cb microchips and i get the same results, so i think its probably something i didn't do
    Images

    • 123.JPG

      58.29 kB, 671×338, viewed 1,107 times

    The post was edited 1 time, last by scarywater ().

  • Hi,
    perhaps this is a similar issue I face in "No matching RAMCode found" - STM32 and J-Link. I also tried to write contents to FLASH via loadbin using J-Link Commander to STM32F103 controller. It had no effect, but also no error was indicated.
    When flashing via JTAG and GDBServer a verification takes place - and then, a verification error notice is raised (details in the other thread).
    Cheers
    christoph

    The post was edited 2 times, last by christoph ().

  • aah, thank you so much, the thread actually helped, the problem wasn't the RAMcode or anything, it's just that i selected the wrong chip as well, hahahah the markings on the chip is a bit worn and the writing is small, i thought it read STM32F103CBT6 when in actual was a STM32F103C8T6 :pinch: hahaha thank you so much

  • Hi,
    that's really good! In the meantime I realized that in fact the line

    Source Code

    1. set mem inaccessible-by-default off

    is not needed at all. At least it "helped" hiding the underlying issue, i.e. selecting the wrong device type, and removed the "RamCode" statement. When you use the the right device, also this "RamCode" message will not appear any longer.

    I am wondering whether Segger could address the consequences of using the wrong device type in their GDB Server Manual FAQ section. This is definitely a beginner's issue, but as Cortex-M3 and the EDU versions of J-Link become more and more popular, the manuals could reflect this and address also some of the hurdles to be taken by non-professionals. ;)
    Cheers
    christoph