Problem with fs_init after importing to Segger Embedded Studio

[phild]

Hi, 

I followed the instructions for importing the Thing:52 firmware into SES and managed to get the firmware compiled and loading, and the code reaches the main function without any apparent problem. When it gets to the application though I get an error in m_ble_flash_init. The problem is in the structure returned by FS_SECTION_ITEM_GET(i) within fs_init (called within m_ble_init->m_ble_flash_init->fsd_init) - particularly in these lines (fstorage.c:363) : - 

p_config_i = FS_SECTION_ITEM_GET(max_index);

        p_config_i->p_end_addr   = p_current_end;
        p_config_i->p_start_addr = p_current_end - (p_config_i->num_pages * FS_PAGE_SIZE_WORDS);

The write of p_current_end to p_config_i>p_end_addr doesn't happen and the value remains 0. The same is true for p_config_i->p_start_addr. 

p_current_end is 0x00080000, i.e. the end of the flash section - as expected. The p_config pointer is pointing to 0x5beac. 

Of course what then happens is that p_current_end gets update to 0x0: - 

p_current_end = p_config_i->p_start_addr;

This causes problems later on. 

There are earlier warnings which Iooked into. The first on happens because all the structure values are 0, so the drv_ext_light_off driver tries to setup a timer with timeout_ticks = 0, so this generated an NRF_ERROR_INVALID_PARAM error. 

It seems these errors could all be down to the same root cause - the inability to write to these structures. 

Any idea what I am doing wrong? 

Thanks in advance for any help.

Phil.

p.s. If it is useful - here is the trace from the debug console.

 main :INFO:===== Thingy started! =====

drv_ext_light :WARNING:Err code returned in file: /Users/derrick/work/third-party/Nordic-Thingy52-FW/source/drivers/drv_ext_light.c, line: 754, code 7 
drv_ext_light :WARNING:Err code returned in file: /Users/derrick/work/third-party/Nordic-Thingy52-FW/source/drivers/drv_ext_light.c, line: 858, code 7 
drv_ext_light :WARNING:Err code returned in file: /Users/derrick/work/third-party/Nordic-Thingy52-FW/source/drivers/drv_ext_light.c, line: 754, code 7 
drv_ext_light :WARNING:Err code returned in file: /Users/derrick/work/third-party/Nordic-Thingy52-FW/source/drivers/drv_ext_light.c, line: 858, code 7 
m_env :INFO:Init: 
m_motion :INFO:Init 
m_sound :INFO:Sound_init 
m_ble :WARNING:Too few random bytes available. Trying again 
m_ble :WARNING:Too few random bytes available. Trying again 
m_ble :WARNING:Too few random bytes available. Trying again 
m_ble :INFO:Available random bytes: 16 
m_ble :INFO:Random value (hex): 2x2x2x2x
m_ble_flash :INFO:Initialization
m_ble_flash :WARNING:Err code returned in file: /Users/derrick/work/third-party/Nordic-Thingy52-FW/source/modules/m_ble_flash.c, line: 197, code 11 
m_ble :ERROR: m_ble_flash_init failed - 11
main :ERROR: id = 16385, pc = 0, file = /Users/derrick/work/third-party/Nordic-Thingy52-FW/project/pca20020_s132/main.c, line number: 304, error code = 11 = NRF_ERROR_INVALID_DATA

[phild]

So it fails because the call to app_timer_start is made with app timer ticks of 0. To workaround this I have to set the sequence_vals in drv_ext_light_off to be non-zero which then executes a different code branch (LED_DRV_ENABLED_BLINK_OR_BREATH) in m_ioext_cmd_process. Without this, the LED_DRV_ENABLED_SINGLE_SHOT branch is executed which sets active_time_ms based on the zero sum of the fade_in, on and fade_out times -> thus the error on app_timer_start. 

I'm not sure how this is meant to work.

Here is my modified version of drv_ext_light_off.

ret_code_t drv_ext_light_off(uint32_t id)
{
    ret_code_t err_code;

    VALID_LIGHT_ID_CHECK(id);

    NRF_LOG_DEBUG("Light off \r\n");

    drv_ext_light_rgb_sequence_t sequence;
    sequence.sequence_vals = SEQUENCE_DEFAULT_VAL;
    sequence.sequence_vals.on_intensity = DRV_EXT_LIGHT_INTENSITY_OFF;
    sequence.color = DRV_EXT_LIGHT_COLOR_WHITE;
    sequence.sequence_vals.fade_in_time_ms = 900;
    sequence.sequence_vals.on_time_ms = 100;
    sequence.sequence_vals.fade_out_time_ms = 900;
    sequence.sequence_vals.off_time_ms = 100;
    sequence.sequence_vals.on_intensity = 0xff;
    sequence.sequence_vals.off_intensity = 100;

    err_code = m_ioext_cmd_process(id, &sequence);
    RETURN_IF_ERROR(err_code);

    return DRV_EXT_LIGHT_STATUS_CODE_SUCCESS;
}

[phild]

Although it looks like this may be the LED for the colour sensor (the one next to the colour sensor) so this probably needs to be off...

[phild]

I now have this working. The two things I had to change were: - 

1. Edit the flash_placement.xml file to copy the fs_data to RAM (although this defeats the purpose of using flash storage?) and

2. Workaround the round functions in optimal_time_settings_risefall_calculate() - the input to this function turns out to be 0/0 for drv_ext_light_off. Workaround is to check if the dividend is '0' before using the round function - and if it is just use 0 for the value. This then allows the correct selection of  LED_DRV_DISABLED_LIGHT_OFF in m_io_ext_oper_mode_chk (called from m_ioext_cmd_process).

Fixed code can be found in the ses_import branch under

https://github.com/phild68/Nordic-Thingy52-FW.git

[Edvin]

Hello Phil, 

I worked quite a bit on this on Friday. I am not done just yet, but me and a co-worker tried to port the Keil project from scratch. I had some path problems with your project, so we decided to go with a fresh install of the SDK for Thingy. I worked on the LED drivers, and I found the same issue as you. I guess that the Math libraries for Keil and SES works a bit differently. My solution was to just round up the ticks-variable in app_timer_start(..., ticks, ...) to be minimum APP_TIMER_MIN_TIMEOUT_TICKS:

 

            if (power_optim_possible)    
            {
                m_p_light_conf[id].p_data->p_status->inactive_time_ms = 0;

                m_p_light_conf[id].p_data->p_status->active_time_ms = p_sequence_real_vals->sequence_vals.fade_in_time_ms +
                                                                      p_sequence_real_vals->sequence_vals.on_time_ms +
                                                                      p_sequence_real_vals->sequence_vals.fade_out_time_ms;
                
                uint32_t ticks = APP_TIMER_TICKS( m_osc_on_margin_calculate(m_p_light_conf[id].p_data->p_status->active_time_ms));
                
                if (ticks < APP_TIMER_MIN_TIMEOUT_TICKS)
                {
                    ticks = APP_TIMER_MIN_TIMEOUT_TICKS;
                }
                err_code = app_timer_start(m_p_light_conf[id].p_data->timer, ticks, (void*)id);
                RETURN_IF_ERROR(err_code);

(from line ~744 in drv_ext_light.c)

 

I didn't get the flash storage issues, but my colleague did. I have to check with him later today, but if I remember correctly, we managed to fix it. I will get back to you later today. I just wanted to give you a status update.

 

Best regards,

Edvin

[Edvin]

Hello,

I think I found the issue with the flash.

I assume that you have seen this porting guide to port projects from Keil to SES.

 

I see that our thumb_crt0.s are a bit different. I use Segger Embedded Studio v3.40. I suspect that many of the differences are a due to that we use different versions, but as it mentions in the guide, you should change one thing in your thumb_crt0.s file.

ldr r2, =__tdata_end__
bl memory_copy
# ADD HERE ... 
ldr r0, =__fs_data_load_start__
ldr r1, =__fs_data_start__
ldr r2, =__fs_data_end__
bl memory_copy
# TO HERE ...

I see that you have something similar, but there is some typos.

In your thumb_ctr0.s it says:

  ldr r0, =__fs_data_load_start__
  ldr r1, =__start_fs_data
  ldr r2, =__stop_fs_data
  bl memory_copy

Try to change

__start_fs_data   and 

__stop_fs_data

to

__fs_data_start__    and

__fs_data_end__

as it says in the porting guide. Also, try to use the flash_placement.xml file to the one that is linked in the guide (the one that is meant for sdk14).

I see that you have copied the thumb_crt0.s, which is fine. Just a note to anyone else might reading this post that if you change the thumb_crt0.s, this might affect the SES projects from the "normal" SDK examples using SES.

 

My workaround for the light drivers are working, but they are maybe not optimal. They need some more tests. It would be great if you find that my (or your) LED driver workaround causes some other issues

 

Best regards,

Edvin

 

Best regards,

Edvin