beemac
10 kW
casainho said:
Ok - i got some semblance of debugging going today. It's a bit flaky and needs to be restarted a lot - plus for some inexplicable reason breakpoints only seem to work in main.c
I still can't see why in assist level 3 the packets stutter more and are sent at a lower rate. Not sure if you can do profiling using these tools - but as yet I can't find how to see where the cpu is spending most time...
I did however remove motor_controller and almost all of the ebike_app_controller loop -
Code:
void ebike_app_controller(void)
{
//throttle_read();
//torque_sensor_read();
//read_pas_cadence();
//calc_pedal_force_and_torque();
//calc_wheel_speed();
//calc_motor_temperature();
ebike_control_motor();
communications_controller();
check_system();
}And the problem of the stutter (comms pauses for about 0.2s i reckon) still remains... that was as much I could remove easily from the loop without it crashing.
I can see what I believe is a problem though - in the function below - the last //ui8_comm_error_counter++; I think is unnecessary.
Because communications_controller() runs every cycle that there is enough time to run ebike_app_controller(); - if there isn't a packet ready for it to process - it increments the error counter. I think it's enough to only inc the error counter if the crc fails to validate. If you do this - then I typically get one error in level 3 - as opposed to 11...
It might be that the stutter is actually the UART refusing to receive for whatever reason for a short period and so the loop runs a few times with no packets to process -hence this code causing the too many errors to trigger.
Code:
static void communications_controller(void)
{
uint8_t ui8_frame_type_to_send = 0;
uint8_t ui8_len;
if (ui8_received_package_flag)
{
// just to make easy next calculations
ui16_crc_rx = 0xffff;
ui8_len = ui8_rx_buffer[1];
for (ui8_i = 0; ui8_i < ui8_len; ui8_i++)
{
crc16(ui8_rx_buffer[ui8_i], &ui16_crc_rx);
}
// if CRC is correct read the package
if (((((uint16_t) ui8_rx_buffer[ui8_len + 1]) << 8) +
((uint16_t) ui8_rx_buffer[ui8_len])) == ui16_crc_rx)
{
ui8_comm_error_counter = 0;
if (ui8_m_motor_init_state == MOTOR_INIT_STATE_RESET)
ui8_m_motor_init_state = MOTOR_INIT_STATE_NO_INIT;
ui8_frame_type_to_send = ui8_rx_buffer[2];
communications_process_packages(ui8_frame_type_to_send);
}
else
{
ui8_received_package_flag = 0;
ui8_comm_error_counter++;
}
}
else
{
//ui8_comm_error_counter++;
}Another oddity i see - is that empty config (and other short) packets are sent with a short length - but are then padded up to 29 bytes. This looks like errors to my receiver as it violates the spec as i've interpreted it but I guess it's tolerated by the wireless controller... It's because UART_NUMBER_DATA_BYTES_TO_SEND (=29) is used as the packet length to send - not the actual packet length - is that intended?
e.g. the below packet should only be 3 bytes as it has zero length.
rE480:cE480 43 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Code:
void UART2_TX_IRQHandler(void) __interrupt(UART2_TX_IRQHANDLER)
{
if (UART2_GetFlagStatus(UART2_FLAG_TXE) == SET)
{
if (ui8_m_tx_buffer_index < UART_NUMBER_DATA_BYTES_TO_SEND) // bytes to send
{
// clearing the TXE bit is always performed by a write to the data register
UART2_SendData8(ui8_tx_buffer[ui8_m_tx_buffer_index]);
++ui8_m_tx_buffer_index;
if (ui8_m_tx_buffer_index == UART_NUMBER_DATA_BYTES_TO_SEND)
{
// buffer empty
// disable TIEN (TXE)
UART2_ITConfig(UART2_IT_TXE, DISABLE);
}
}
}
else
