7 Replies Latest reply on Sep 22, 2019 2:00 PM by ilg

    Using qemu-system-gnuarmeclipse command-line for nrf52840

    ramkumar.dce
      0

       

       

      I want to run unit-tests for a firmware code written for nrf52840 using QEMU. I came across the GNU MCU Eclipse project which has forked the main QEMU project to provide better support for Cortex-M SoCs by allowing the creation of cortex-m devices through data definitions provided in CMSIS SVD files (as noted here). Even though the project primarily supports the STM32 based boards and MCUs, the corresponding eclipse plugin does support adding new device packs for development and debugging. But I am not able to figure out how to use the command-line tool qemu-system-gnuarmeclipse to run an ELF file created for nrf52840. I have the following questions:

      1. How does eclipse plugin allow debugging for nrf52840 using custom SVD file even though the command-line tool doesn't have any option to provide a custom SVD file?
      2. How can I add support for nrf52840? Can I reuse board and MCU definitions for STM32 and just provide a JSON variant for SVD file here?
        • Re: Using qemu-system-gnuarmeclipse command-line for nrf52840
          ilg

          > I want to run unit-tests for a firmware code written for nrf52840 using QEMU

           

          yes, this is a generous idea, but it is realistic only for tests that do not use any hardware resources, like portable libraries, and in this case you can run the tests on any other existing board/device.

           

          > How does eclipse plugin allow debugging for nrf52840 using custom SVD file even though the command-line tool doesn't have any option to provide a custom SVD file?

           

          the debug plug-ins allow debugging any device with any custom SVD as long as your device is supported by the debugger.

           

          > How can I add support for nrf52840? Can I reuse board and MCU definitions for STM32 and just provide a JSON variant for SVD file

           

          extend QEMU requires more than adding a JSON, you need to add callbacks to implement the functionality for each new register.

          1 of 1 people found this helpful
            • Re: Using qemu-system-gnuarmeclipse command-line for nrf52840
              ramkumar.dce

              Thanks and really appreciate your prompt response here.

               

              > but it is realistic only for tests that do not use any hardware resources

               

              While for pure unit tests, the strategy should be to mock out any dependencies, but for integration tests we do want to verify things like writing to a file in flash, verifying that a freertos task is able to run and context switch tasks etc. Isn't the benefit of using QEMU is to allow verifying these integrations by translating such calls of a guest OS to a host OS?

               

              > extend QEMU requires more than adding a JSON, you need to add callbacks to implement the functionality for each new register.

               

              I could see that SVD files can be used to auto-generate code for modelling peripherals using xsvd tool as noted here. Is there some gnu-mcu-eclipse-qemu specific documentation that I can follow or template that I can use to add the support for new MCU? or do I need to follow the original QEMU documentation to create custom machine? My understanding is that the key motiviation of the eclipse fork of QEMU was to simplify adding support for new MCU.

               

               

                • Re: Using qemu-system-gnuarmeclipse command-line for nrf52840
                  ilg

                  > for pure unit tests, the strategy should be to mock out any dependencies

                   

                  that's correct and these tests run very well on QEMU, regardless the board, as long as the device uses the same architecture.


                  > for integration tests we do want to verify things like writing to a file in flash

                   

                  with some effort this can also be done, and it is also possible at the end of the emulation to write the flash content to a file, and reuse it in a subsequent session.

                   

                  however this feature is not yet implemented.

                   

                  > verifying that a freertos task is able to run and context switch tasks

                   

                  this is also perfectly possible, and the µOS++ framework (including the RTOS preemptive scheduler) was developed mostly (90%?) while running on QEMU and as a POSIX process on macOS.

                   

                  the Cortex-M SysTick and a few specific system registers are available and context switches run very well. however, floating point support is not functional, so only non-FP devices are supported.

                   

                  > Is there some gnu-mcu-eclipse-qemu specific documentation that I can follow or template that I can use to add the support for new MCU?

                   

                  unfortunately not much, the source code itself.

                   

                  >  the key motivation of the eclipse fork of QEMU was to simplify adding support for new MCU

                   

                  yes, and to experiment with automatic code generation. as a first iteration, the results are encouraging, but further improvements are possible.

                   

                  however my resources are limited, and for now I cannot dedicate too much time to this second iteration of QEMU, but if I find someone to work with, I may change priorities.

              • Re: Using qemu-system-gnuarmeclipse command-line for nrf52840
                clem57
                Some vendors also provide definitions for some system devices in the SVD files (line NVIC in STM32 files). Because there is no guarantee that the register names and fields are kept consistent, these definitions are ignored and the system peripherals are created using separate definitions.

                This statement is why you cannot simulate operations on flash etc...